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Arrangements and method for handling macro diversity in a Universal Mobile 
Telecommunications System 

Field of the invention 

The present invention relates to arrangements and a method in a third 
generation mobile telecommunication system and evolved variants thereof. In 
patlicular, the invention relates to arrangements and a method for handling 
macro diversity in a UMTS Radio Access Network (UTRAN). 

Background 

Third generation mobile communication systems (3G, UMTS-Universal Mobile 
Telecommunications System) shall offer high quality voice and data services for 
mobile users. The systems shall also provide high capacity and universal 
coverage. In some situations that may however be difficult to fulfil, due to 
unreliable radio channels. One promising technique to combat link reliability 
problems over the radio interface is macro diversity techniques. Macro diversity 
should however also be seen as an inherent consequence of using Code 
Division Multiple Access (CDMA) as the multiple access technique in a cellular 
network. CDMA is an interference limited technology. That is, it is the 
interference in a cell that sets the upper limit for the cell's capacity. To keep 
the interference as low as possible it is essential that the base station controls 
the output power of the radio transmitters of the mobile terminals in the cell, 
i.e. fast and efficient power control is essential. As a mobile terminal moves 
towards the peripheiy of a cell it has to increase the power of its radio 
transmission in order for the base station to be able to receive the transmitted 
signal. Likewise, the base station has to increase the power of its radio 
transmission towards the mobile terminal. This power increase has a 
deteriorating effect on the capacity of both the mobile terminal's own cell and 
the neighbouring cell(s) which the mobile terminal is close to. Macro diversity 
is used to mitigate this effect. When the mobile terminal communicates via 
more than one base station, the quality of the communication can be 
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maintained with a lower radio transmission power than when only a single 
base station is used. Thus, macro diversity is both a feature raising the quality 
of unreliable radio channels and a necessity that is required in order to 
overcome an inherent weakness of CDMA based cellular systems, 

5 - • , • * ' 

Figure 1 iUustrates a UTRAN. The Radio Network ControUer (RNC) is 
connected to the Core Network that in turn may be connected to another 
network. The RNC is connected to one or more Node Bs also denoted base 
stations via a transport network. The transport network may e.g. be IP-based 

10 or ATM-based. Hie transport network nodes are indicated with a 'T*' in figure 

1. In an IP based transport network these nodes are IP routers. In an ATM 
based transport network the transport network nodes are AAL2 (ATM 
Adaptation Layer type 2) switches. The Node Bs may be wirelessly coimected to 
one or several User Equipments (UEs) also denoted mobile terminals- A 

15 Serving-RNC (S-RNC) is a RNC that has a Radio Resource Connection (RRC) 

connection with the UE. A Drift-RNC (D-RNC) is a RNC that may be connected 
to a UE, but where another RNC, i.e. the S-RNC, handles the RRC connection 
with the UE. 

Macro diversity enables a mobile terminal to communicate with a jSxed network 
by more than one radio link, i.e. a mobile terminal can send/receive 
information towards/from more than one radio port (or base station also 
denoted Node B). The radio ports (RPs) are spatially separated at distance from 
a short distance, e.g. between different floors in a building, (pico-cells) up to 
about some kilometres (micro- and macro-cells). As the propagation conditions 
between the mobile terminal and the different RPs, are different at the same 
moment in time, the resulting quality of the combining of the received signals 
is often better than the quality of each individual signal* Thus, macro diversity 
can improve radio link quality. When a mobile terminal is connected to more 
than one base station simultaneously, the UE is said to be in soft handover. 
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Macro diversity is appUcable only to dedicated channels (DCH). Currently all 
the macro diversity functionality resides in the RNC (the corresponding 
functionality for softer handover in Node B is not considered.) In the downUnk, 
the spUtting is performed in the RNC, which ensures that a copy of each 
5 downlink DCH FP frame is sent through each leg in the active set of the 

concerned DCH. Both DCH FP data frames and DCH FP control frames are 
subject to the splitting function. 

In the uplink, the RNC performs the combining, which naturally is more 
10 complicated than the splitting. Only DCH FP data frames are subject to the 

combining procedure. DCH FP control frames are not combined, since each 
uplink DCH FP control frame includes control data that is specific for an 
individual Node B. For the uplink, the RNC has a time window in which aU legs 
are expected to deliver their contribution to the frame combining (i.e a DCH FP 
15 frame with a certain Connection Ftame Number (CFN)). At the esqriration of the 

time window, all the DCH FP frames with the correct CFN that were received 
within the time window are passed to the combining function. 
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The actual combining is a simple selection of the best piece of data out of the 
candidates that were received throu^ the different legs. For non-voice DCHs, 
the unit of selection is a transport block (TB). To determine which of the 
candidates to select for a certain transport block, the CRCI for the concerned 
TB is checked in each of the deUvered frames. If one and only one of them 
indicates that the TB was correctly received at the Node B (i.e. that the CRC 
25 check was successful for the concerned TB when it was received by the Node 
B), this TB is selected. Otherwise, if more than one of the CycUc Redundancy 
Checksum Indicators (CRCI) indicate successful CRC check, the combining 
function selects the one of these TBs that belong to the frame with the greatest 
QuaUty Estimate (QE) parameter. Likewise, if all of the CRCIs indicate 
unsuccessful CRC check, the combining function selects the TB from the frame 
with the greatest QE parameter. If in the two latter cases, the greatest QE 
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parameter value is found in two or more of the frames {i.e. if these QE 
parameters are equal too), the selection of TB is implementation dependent. 
Figure 2 illustrates the combining procedure for non-voice DCHs. 

For voice DCHs the combining works slightly differently. The AMR (Adaptive 
Multi Rate) speech codec produces three subflows, vsrherein each are 
transported in a respective DCH. These three DCHs are so-called coordinated 
DCHs. The coordinated DCHs are included in the same DCH FP frame and 
there is only one TB for each subflow in a frame. During the combining, the 
combining Sanction does not select separate TBs from different candidate 
frames to create a new combined frame as described above in the context of 
non-voice DCHs! Instead it selects one entire frame based on the CRCI for the 
TB associated with subflow.l, which is the most significant subflow. The CRCI 
of the other subflows are insignificant, since these subflows are not CRC 
protected over the radio interface. Again, if the CRCIs indicated unsuccessful 
CRC check or because all of the concerned CRCIs indicate unsuccessful CRC 
check, the frame with the greatest QE parameter is selected. Figure 3 
iUustrates the combining procedure for voice DCHs. 

Hence macro diversity in current UTRANs is reaKsed through macro diversity 
functionaKty, also denoted as Diversify Handover (DHO) functionaUty in the 
RNCs, The current standards allow DHO functionaHty in both the Serving RNC 
(S-RNC) and the D-RNC, but the possibiHty to locate the DHO fonctionality in 
the D-RNC is commonly not used. 



Thus, a problem in the existing macro diversity solutions is that the split 
downlink flows and the uncombined uplink flows of user data are transported 
all the way between the RNC and the Node B. That results in that costly 
transmission resources are consumed in the UTRAN transport network, which 
30 also restdts in significant costs for the operators. 
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giimfnarv nf ths invention 

The consumed transmission resources are reduced according to the present 
invention by distributing the macro diversity functionaUty to the Node Bs. A 
problem is then how to select which of the connected Node Bs that should be 
selected to perform the combining/ spUtting function, also referred to as a 
Diversity Handover (DHO) function. These selected nodes are referred to as 
DHO nodes. The DHO nodes have to be selected out of those Node Bs that are 
able to perform the DHO fUnctionalily. i.e. out of those Node Bs that have been 
adapted with DHO functionality and other functions of the present invention. 
These nodes are referred to as DHO enabled nodes or macro diversity enabled 
nodes. 

The object of the present invention is to solve the above stated problem. 

The problem is solved by the arrangements according to claims 25,26,27 and 
29 and the methods of daim 1 and 28. 
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The most important advantage achieved by the present invention is 
transmission savings in the UTRAN transport network, which translate into 
significant cost savings for the operator. The transmission savit^s are reaUsed 
through optimised location the DHO functionaHty. Thereby the redundant data 
transport is eliminated in the parts of the path, where data pertaining to 
different macro diversity legs of the same DCH would otherwise be transported 
25 in parallel along the same route. 

Another advantage of the present invention is that it facilitates that RNCs may 
be located in more central locations of the network (i.e. with less geographical 
distribution). The main purpose of the current common geographical 
30 distribution of RNCs is to limit the transmission costs for the parallel macro 
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diversity legs. When this parallel data transport is eliminated, it becomes more 
beneficial for an operator to centralise the RNCs, e.g, by co-locating them with 
MSCs or MGWs. Co-locating several nodes on the same site results in 
simplified operation and maintenance, which also means reduced costs for the 
^ 5 operator. 

Brief description of the drawings 

Figure 1 is a schematic illustration of a UMTS Terrestrial Radio Access 
Network 

10 Figure 2 illustrates the combining procedure for non-voice DCHs. 

Figure 3 illustrates the combining procedure for voice DCHs. 

Figure 4 illustrates the potential transmission savings in an example with 
cascaded Node Bs according to the present invention. 

Figure S illustrates a scenario with a mobile terminal using five macro 
1 5 diversify legs according to the present invention. 

Figure 6 shows a route tree resulting from the exemplified scenario of figure 5. 

Figure 7. shows the branching node tree corresponding to the route tree in 
figure 6, 

Figure 8 shows the DHO node tree resulting from the selection of DHO nodes 
20 corresponding to the branching nodes of the example depicted in figure 5. 

Figure 9 shows the DHO node tree of figure 8 mapped on the route tree of 
figure 6 with the resulting potential data flows. 

Figure 10 shows the modified DHO node tree after the first step of the delay 
: reduction method number 5 according to an embodiment of the invention, 

* ' 25 Figure 1 1 shows the potential data flows in the route tree after the first step of 

* • « 

• - : the delay reduction method number 5. 

* ♦ * 

: \ % Figure 12 shows the modified DHO node tree after the second step of the delay 

reduction method number 5 according to an embodiment of the invention. 
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Figure 13 shows the potential data flows in the route tree after the second step 
of the delay reduction method niimber 5. 

Figure 14 shows the modified DHO node tree after the third step of the delay 
reduction method number 5 according to an embodiment of the invention. 
5 Figure IS shows the potential data flows in the route tree after the third step 

of the delay reduction method number 5. 

Figure 16 shows the modified DHO node tree after the first step of the delay 
reduction method number 6 according to an embodiment of the invention. 
Figure 17 shows the potential data flows in the route tree after the first step of 
10 the delay reduction method number 6. 

Figure 18 is a flowchart of one of the methods according to the present 
inv«ition. 



Detailed description 

15 The present invention will now be described more fuUy hereinafter with 

reference to the accompanying drawings, in which preferred embodiments of 
the invention are shown. This invention may, however, be embodied in many 
different forms and should not be construed as limited to the embodiments set 
forth herein; rather these embodiments are provided so that this disclosure 

20 wiU be thorough and complete, and will fully convey the scope of the invention 

to those skilled in the art. In the drawings, like numbers refer to like elements. 

In the further description of the present invention coordinated DCHs are not 
speciflcaUy treated. In the aspects that are significant to the present invention 

25 a set of coordinated DCHs is treated in the same way as a single separate 

DCH. The DCHs of a set of cooixiinated DCHs use a common transport bearer 
and in an IP UTRAN the fi-ames (of a set of coordinated DCHs) with the same 
CFN are indudfed in the same UDP packet. The special combining procedure 
for coordinated DCHs has been described above. Thus, omitting coordinated 

30 . DCHs serves to simplify the description of the present invention and makes the 
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text more readable. To generalize the description of the present invention so as 
to comprise coordinated DCHs would be conceptually trivial for a person of 
ordinary skills in the art, althou^ it would significantly compUcate the text. 

the present invention may be implemented in a third generation mobile 
telecommunications system, e.g. in a UMTS, and in particular in the Radio 
Access Network (RAN), e.g. a UMTS Terrestrial Radio Access Network, UTRAN. 
Such a system is illustrated in figure 1 and described above in coiyunction 
with figure 1. 

In order to reduce the required transmission resources, the present invention 
proposes to distribute the macro diversity functionalily to the Node Bs from 
the RNC for macro diversity configurations for which this is beneficial from a 
transmission point of view. The potential transmission savings are illustrated 
in figure 4. When a macro diversity configuration is estabUshed, or changed, it 
is first required to select the Node Bs that should be the Diversity Handover 
(DHO) nodes, i.e. the Node Bs that should perform the actual combining and 
splitting. The DHO nodes have to be selected out of the available nodes that 
comprise DHO functionality, i.e. out of the DHO enabled nodes (typically DHO 
enabled Node Bsj.In order to select the DHO nodes, the first step that is 
performed is to obtain topology information of the UTRAN transport network 
and how the nodes within the transport netwoik are connected to the Node Bs. 
The topology information may for example be obtained in the topology map 
illustrated in figure 5. 



The topology mformation is according to the present invention obtained by 
developing a topology database. The topology database is adapted to provide 
the RNC with the information the RNC needs in order to determine when 
distribution of the DHO functionaHty to the Node Bs is beneficial and to select 
the Node Bs to be involved. The topology database is first described for an 
Internet Protocol (IP) based UTRAN, including its general properties and ways 
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to create it. Then, in a further section, the topology database for an ATM based 
UTRAN is described. 

The selection of the DHO node(s) requires that the RNC comprises or is 
adapted to retrieve information about the topology of the UTRAN, both the 
UTRAN transport network and the Node Bs and RNCs. Different levels of 
richness of this information are conceivable. The choice of this level is a trade- 
off between the value it provides for the DHO node selection mechanism and 
the complexity it impUes for the selection mechanism as well as the topology 
information retrieval mechanism. A certain level of flejdbihty of the richness of 
the topology information will be allowed in the further description of the DHO 
node selection. 

However, the topology information with a basic level of richness comprises 
according to the present invention: 

-A hop-by-hop route firom the RNC to each Node B that is controUed by the 
RNC and possibly some Node Bs that are controlled by neighboring RNCs, 
wherdn each router is represented by the IP address associated with the 
interface that is used to forward packets in the direction of the RNC. The Node 
B is represented by one of its IP addresses, e.g. the one used for NBAP 
signaling (or the primary IP address used for NBAP signaling in case multiple 
IP addresses are used for NBAP agnaling). If a neighboring RNC is included in 
a hop-by-hop route, it is also represented by one of its IP addresses, e.g. the 
one used for RNSAP signaling (or the primary IP address used for RNSAP 
signaling in esse multiple IP addresses are used for RNSAP signaling). 

-A delay metric for each hop in a route. If no expUcit delay metric is available, 
an approximation can be derived from the generic cost metric, which is 
described below, or all hops can be given the same delay metric. 
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-A generic cost metric for each hop in a route. If no such g^eric cost metric is 
expHcitly available, a reasonable approximation can be derived from the delay 
metric or a fixed default cost metric can be used for aU hops. 

Preferably, the RNC is adapted to use the topology information to maintain 
data representations of the hop-by-hop routes with associated metrics to all 
the Node Bs in the Radio Network Subsystem (RNS) (and possibly to some 
Node Bs controlled by neighboring RNCs, i.e. Node Bs in neighboring RNSs). 
The RNS comprises the RNC and the Node Bs that are controUed by the RNC. 
Then the routes are readily available when needed for a DHO node selection 
process. However, retrievmg topology information and creating the hop-by-hop 
routes in real-time when needed is also a possibiUty if the RNC maintains a 
generic topology database. For instance if the Transport Network Layer (TNL) in 
the RNC maintains a link state routing topology database, it is conceivable that 
this database is consulted (e.g. by letting the Radio Network Layer (RNL) of the 
RNC interrogate the TNL of the RNC) in order to create the required hop-by- 
hop route representations in real-time. From a performance perspective it is 
preferable that the hop-by-hop routes are readily available when they are 
needed. 



hi addition to the required topology information the RNC must be manually or 
automatically configured with knowledge about tiie relevant Node Bs that are 
able to comprise DHO functionaUty, also referred to as DHO enabled nodes. 
The DHO enabled nodes are at least constituted by the DHO enabled nodes 
controUed by the RNC, but in inter-RNS macro diversity configurations they 
may also include other RNCs and Node Bs controlled by other RNCs. It is also 
possible that the DHO enabled nodes may include other, yet non-existing, 
types of Radio Network Layer (RNL) nodes, e.g. specialized DHO nodes. The 
RNC is required to know one IP address of each DHO enabled node, preferably 
the IP address used for NBAP signaling (or RNSAP signaling in the case of an 
RNC). This IP address is required to be the same IP address as is used to 
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represent the node in a hop-by-hop route. The RNC may be adapted to use the 
list of DHO enabled nodes to include an indication of whether the node is DHO 
enabled or not for each node in the hop-by-hop routes. 

5 According to embodiments of the present invention, there are four possible 

ways for an RNC to provision the required topology information: 
1 . Through manual or semi-automatic management operations. When 

the UTRAN (including its transport network) is built or changed, the relevant 
topology information is configured in the RNC via 08sM means. 

10 2. Via a link state routing protocol. If a link state routing protocol, e.g. 

Open Shortest Path First (OSPF), is used in the UTRAN transport network, the 
RNC may be adapted to participate in the routing protocol communication as if 
it were a router. However, assuming that the RNC does not have a router 
function (i.e. the IP forwarding ftinction) it would not announce reachability to 

1 5 any other network than the site infrastructure LAN. Therefore, in practice, no 

node would ever attempt to use the RNC as a transit node, a node that 
forwards traffic, i.e. a node that is neither the source node nor the destination 
node. Thus, through the routing protocol the RNC comprises means for 
maintaining an up-to-date topology database, without being required to 

20 perform other router functions. 

3. By using a traceroute mechanism that allows the RNC to discover the 
hop-by-hop route to each Node B. The traceroute mechanism is described in 
detail below. 

4. By retrieving topology information from another RNC. However, this 
25 method is only feasible in the inter-RNs case. 

The third of the above listed ways to provision topology information, i.e. the 
traceroute mechanism, requires a further detailed description. Since the 
destination nodes, i.e. the Node Bs, are not arbitirary nodes in the network, 
30 they may be prepared for the traceroute messages. This allows the traceroute 
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program to work sUgbtly differently from traditional traceroute programs 
(althou^ a traditional traceroute program would work too). A future IP based 
UTRAN will assumedly use IPv6, but for completeness an RNC traceroute 
program variant for IPv4 is alsp described. 

The RNC traceroute program for IPv6 uses a dedicated UDP port, the same 
source and destination port in both the RNC and the Node Bs, To begin the 
process, the traceroute program sends a UDP message with the UDP source 
and destination ports set to the dedicated port and with the destination 
address in the IP header set to the IP address used for NBAP signaling with the 
target Node B. The traceroute program also sets the hop limit field in the IP 
header to one and includes the time of sending as accurately as possible and a 
copy of the hop limit field in the UDP payload. The fact that the hop limit of the 
IP packet is set to one causes the first router in the path to discard the 
message and return a Time Exceeded ICMPv6 Message to the RNC. The Time 
Exceeded Message includes up to 1232 octets of the invoking message. Since 
this is far greater than the message sent by the RNC, the entire invoking 
message will be included. 

When receiving the Time EKceeded Message the RNC is looking at the source 
address and the included message. In the included messe^e the IP destination 
address informs the RNC which Node B route the message concerns, the hop 
limit field copy in the included UDP payload informs the RNC of the number of 
hops to the router that generated the Time Exceeded Message, and the 
recorded time of sending in the included UDP payload allows the RNC to 
calculate the round trip time from the RNC to the router and back. The source 
address in the IP header (of the Time Exceeded Message) provides an IP 
address of one of the routers (in this case the first router since the hop limit 
was set to one) to the RNC in the route towards the target Node B. 
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Next the RNC sends a second message, Tvhich differs from the first one in that 
the hop limit is increased to two (and that the time of sending is different). The 
RNC keeps sending messages with increasing hop limits until one of the 
messages reaches the target Node B. When the target Node B receives the 
message it extracts the hop limit copy and the time of sending from the 
received message and includes them in the payload of a new UDP message that 
is sent to the RNC (using the same dedicated port as source and destination 
port in the UDP header). The Node B may also be adapted to indude additional 
information in the UDP payload, such as information about the link to which 
the Node B is connected e.g. bit rate, delay information, whether the Node B 
has an integrated router or not, etc.. Another useful piece of information that 
the Node B could include in the UDP payload is an indication of the level of 
support for the hierarchical DHO scheme. Three possible support levels may 
be indicated: DHO enabled, not DHO enabled but aware of the hierarchical 
DHO scheme, or no support at all (which would be the default when no 
indication at all is included in the UDP payload when such an indication is 
ejcpected). Such an indication woxUd provide the RNC with automatic 
configuration of the DHO capabiHties of the Node Bs controlled by the RNC. 

When the RNC receives the response messs^e from the Node B it knows that 
one of its messages has reached the target Node B and that it can stop sending 
messages towards that Node B. The source address of the message informs the 
RNC which Node B it concerns. The hop Umit copy in the UDP payload informs 
the RNC of the number of hops to the target Node B and the copied original 
time of sending in the UDP payload allows the RNC to calculate the round trip 
time to the Node B and back. 



If it is not possible to conceive useful additional information to include in the 
response message from the Node B, the traceroute program may be modified. 
Then no program has to run in the Node B and when there is no process 
monitoring the dedicated port, the Node B will return a Destination 
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Unreachable ICMPv6 Message (with the C5ode set to 'port ixnreachableO. In a 
similar way as the Ttaie Exceeded Message, this message comprises the entire 
invoking message. The reception of the Destination Unreachable Message 
(instead of a Time Exceeded Message) informs the RNC that one of its 
messages has reached the target Node B. Then the required information, i.e. 
the source address, the hop limit copy and the original time of sending, may be 
extracted from the messsige. 

Each roundtrip, i.e. a traceroute message and the triggered response message, 
reveals an additional hop in the route towards the destination Node B in terms 
of an IP address (i.e. the IP address that is used to send the IP packets towards 
the RNC) and a delay measure. Thus the RNC may use information revealed by 
a complete set of traceroute messages (and their triggered response messages) 
to build a complete hop-by-hop route from the RNC to a Node B with a delay 
metric associated with each hop. The generic cost metric for each hop is either 
equal to the delay metric for the hop or equal to a fixed value that is the same 
for each hop. 



When IPv4 is used the Time Exceeded ICMPv4 Messagp and the Destination 
Unreachable ICMPv4 Message do not have to comprise more than 28 octets 
the invoking packet. That is, there is room only for the IP header and the UI 
header of the message from the RNC, vdiich means that there is no point to 
include information in the UDP payload (unless the information is intended 
the target Node B). The RNC traceroute program then has to work as 
traditional traceroute programs. That is, for each of its sequentially sent 
messages, it increases the destination UDP port number by one. The RNC is 
also required to store the destination address, the destination port, the hop 
limit and the time of sending for each message that it sends. 



When a Time Exceeded Message is received, the RNC can use the destination 
address and the destination port ui the included UDP header as keys to find 
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the hop limit and the time of sending of the invoking messages- The RNC then 
has aU the required information, i.e. the source address (of the Time Exceeded 
Message), the original hop limit and the original time of sending. Thus, like in 
the IPv6 case, the RNC can use the information revealed by a complete set of 
traceroute messai^s (and their associated response mess^es) to build a hop- 
by-hop route from the RNC to a Node B with a delay metric associated with 
each hop. The generic cost metric for each hop is either equal to the delay 
metric for the hop or. a fixed value that is the same for each hop. 

Normally IPv4 traceroute programs use UDP ports that are unlikely to be used 
by application programs. Thus, the destination node would almost certainly 
return a Destination Unreachable ICMPv4 message. However, there is a small 
risk that an application program is actually using the port in the destination 
node, in which case the traceroute program will fail. To avoid this risk the RNC 
traceroute program in the IPv4 case can use a set of ports that are dedicated 
for this purpose in the Node B. The number of dedicated ports must be at least 
as many as the maximum number of hops between an RNC and a Node B, Like 
in the IPv6 case it is possible to let the Node B include additional useful 
information in its response message to the traceroute message (which response 
message would then be a UDP message). In such case, the program generating 
the response message in the Node B must monitor aU the dedicated ports. 
Otherwise, if no additional useful information is to be included in the response 
messages, the Node B can leave the dedicated ports unmonitored, in which 
case a received traceroute message will trigger a Destination Unreachable 
ICMPv4 message (just like when traditional traceroute programs are used). 

To improve the stability of the traceroute delay measurements, the traceroute 
messages could be sent on high priority bearers, but the response mess^es 
from the Node B shoxUd be sent on the same type of bearer as the ICMP 
messages in order to provide a delay measurement (for tihe last hop) that can 
be compared with the delay measurements for the other hops. However, 
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whether high priority bearers are used or not several traceroute measurements 
should be averaged in order to provide high quality delay measurements. The 
RNC could calculate the averages by repeating complete sets of traceroute 
messages or by repeating each traceroute message in a set. 

Running a number (e.g. 3-5) of traceroute measurements (i.e. sets of 
traceroute messages) towards each base station in the RNS eveiy 24 hours 
would enable the RNC to maintain a reasonably up-to-date topology database 
with reasonably accurate link del^ metrics, while incurring an insignificant 
load in. the transport network. The traceroute measurements should be spread 
out during a period of low traffic load, e.g. during ni^t-time. 

In the case when the UTRAN transport network is ATM based, the topology 
database is based on ATM addresses instead of IP addresses. Otherwise the 
general properties of the topology database are similar to the properties of the 
database in the IP based UTRAN. Each hop in a hop-by-hop route is 
represented by an ATM address. For each hop there is an expKcitly defined or 
impHcitly derived generic cost metric and an explicitly defined or impHcitly 
derived delay metric, to the ATM based UTRAN, the topology database has to 
be created through manual or semi-automatic management operations. The 
RNC uses the topology database in the same way in the ATM based UTRAN as 
in the IP based UTRAN. 

Special considerations are needed when the required topology information is to 
be retrieved for an inter-RNS (inter Radio Network Subsystem) soft handover 
configuration, i.e. when one or more of the involved Node Bs are controlled by 
other RNC(s) than the S-RNC (and thus are located in other RNSs). It is 
assumed that the D-RNC is not necessarily involved in the user plane 
connections, just like common practice is today. Hence, the S-RNC is the 
appropriate node for selection of the DHO nodes also in the inter-RNS case, A 
question is then how the required topology information can be provisioned in 
the S-RNC in the inter-RNS case. 



17 



Configuration through manual or semi-automatic operations is a possibility 
also in the inter-RNS case. An RNC would then be configured not only with the 
topology information of its own RNS, but also with topology information 
pertaining to neighboring RNSs, through which potential inter-RNS soft 
handover connections may be anticipated. However, the more neighbouing 
RNSs to consider in this configuration, the more cumbersome the 
configuration gets. 

A possible way to get around this scaling problem is to configure each RNC 
only with the topology information of its own RNS and then retrieve topology 
information from nei^boring RNCs when needed. If this principle is used and 
topology information fix)m a neigjxboring RNS is needed for selection of DHO 
nodes for an inter-RNS soft handover connection, then the S-RNC requests the 
relevant topology information fi^m the D-RNC. This signaling may consist of 
e.g. a new pair of messages in RNSAP(e.g. called Topology Information Request 
and Topology Information Response). A tricky part in this scenario is to ensure 
that the combined topology information covers also the parts of the transport 
network that interconnect the two RNSs. This may require that all RNCs are 
configured with topology information covering the parts of the transport 
network that is used to interconnect RNSs. Uke in the intra-RNS case manual 
or semi-automatic configuration is the only available means in an ATM 
UTRAN. 



Using the inherent topology information collection mechanisms of a Knk state 
routing protocol in an IP UTRAN is a possibiUty also in the inter-RNS case. 
Depending on how the routers in the transport network are configured, a link 
state routing protocol entity in the RNC could maintain a topology database 
covering several RNSs, maybe even all the RNSs in the UTRAN. If the required 
topology of a neighboring RNS is not known to an RNC, the RNC may request it 
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from the concerned RNC as described above for manually or semi- 
automatically configured topology information. 

Theoretically the traceroute mechanism is possible to use in an IP UTRAN in 
the inter-RNS case too. However, this requires that an RNC includes not only 
the Node Bs of its own RNS in the traceroute scheme, but also all RNS external 
Node Bs (i,e. Node Bs in other RNSs) that potentially could be involved in an 
inter-RNS soft handover coimection. Therefore the traceroute method may be 
hard to realize in the kiter-RNS case. One way would be to configure the RNC 
with all the RNS external Node Bs to include in the traceroute scheme through 
manual or semi-automatic O&M means. Another possibility would be to utilize 
the cell neighbor lists and include in the traceroute scheme all RNS external 
Node Bs that are included in the cell neighbor lists of the cells in the RNS of 
the RNC itself. Yet a possibility would be to use the traceroute mechanism for 
the Node Bs in the RNS of the RNC itself and retrieve topology information 
from other RNCs via signaling (as described above) when needed. 

If a neighboring RNC is included in the topology information, it should be 
represented by an IP address or an ATM address. In an IP UTRAN the IP 
address may e.g, be the IP address used for RNSAP signaling (or the primary IP 
address used for RNSAP signaling in case multiple IP addresses are used for 
this purpose). 

Once the required topology information for neighboring RNS(s) is available 
(irrespective of what provisioning method that was used), the S-RNC uses it in 
the same way as in the intra-RNS case. 

The DHO node selection algorithm 

It should be noted that, although the procedures of the DHO node selection 
algorithm are described below using the terminology of an IP UTBJAN, they are 
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equaUy appUcable in an ATM UTRAN. In an ATM UTRAN the algorithms and 
procedures are the same, but where the routers are replaced by AAL2 switches 
and the IP addresses are replaced by ATM addresses. 

The mechanism that the RNC is adapted to use in order to select the DHO 
node(s), i-e. the node(s) where the splitting and combining will be performed, 
is(are) the same whether optimized NBAP and RNSAP signaling is used or not. 
The object of the DHO node selection mechanism according to the present 
invention is to select the DHO nodes in a way that minimizes one or more 
accumulated metric for the aU the macro diversity legs. According to one 
embodiment of the present invention, such an accumulated metric is a generic 
cost metric. According to a further embodiment this cost metric is put together 
with the condition that for none of the resulting data paths is the resulting 
path delay allowed to exceed a maximum delay value defmed for the UTRAN. 

In the typical scenario, a DCH is first established with a single leg, i.e. without 
macro diversity. When a second macro diversity leg is added, the RNC selects a 
DHO node for these two legs and redirects the existing data flow if necessary 
(i.e. unless the selected DHO node is the Node B of the first leg or the RNC 
itself). When a third leg is added, the RNC is required to rerun the DHO node 
selection process from scratch, since the addition of the third leg may ajffect 
the selection of the first DHO node. The RNC also has the dhoice to let the 
third leg go all the way to the RNC (without trying to find a better DHO node) in 
order to not to affect the previous DHO node choice and to avoid the sigpaHng 
involved in redirecting the existing flows. The same (i.e. renmning the DHO 
node selection process firom scratch or terminating the new leg in the RNC) 
applies to subsequently added macro diversity legs. 

The DHO node selection mechanism relies on the above described topology 
information involving both transport networks nodes (routers) and radio 
network nodes (Node Bs and one or possibly more RNCs), It also utilizies the 
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list of DHO enabled nodes connected to the RNC (and possible some DHO 
enabled nodes in neighboring RNSs 

The RNC selects a first set of preUnjinary DHO nodes in a way that minimizes 
the total accumulated generic cost metrics for the entire macro diversity tree. It 
then checks whether the maximum allowed path delay is exceeded for any of 
the macro diversity legs according to one embodiment. If the path delay is 
acceptable, the set of preliminary DHO nodes is kept. Otherwise the set of 
preUmmary DHO nodes is modified by the RNC in a way that reduces the path 
delays until the path delays of all macro diversity legs are acceptable. 

Selection of the first set of prelim inary DHO nodes 

In short the RNC starts the DHO node selection process by forming a tree of 
the routes (retrieved from the topology database) to the involved Node Bs. It 
then identifies the branching nodes in the tree and their rdative 
interconnections. Identifying the relative interconnections of the branching 
nodes in essence means that the RNC creates a simplified schematic tree 
consisting of only branching nodes, Node Bs and the RNC (i.e. intermediate 
routers are omitted). The simplified schematic tree is illustrated in figuxe 7. 
For each branching node there is a corresponding potential DHO node and the 
RNC is arranged to proceed to select these DHO nodes. A detailed description 
of the complete process follows below. 



An example of the DHO node selection process based on a scenario depicted 
figuxe S will be used throughout the description. The provided example is 
however only included to further facilitate the understanding of the present 
invention and not in order limit the present invention. Figure S illustrates a 
DCH in soft handover mode with five macro diversity legs. The purpose of th^ 
illustrated example is to iUustrate the principles of the DHO node selection 
process. R1-R7 in the fiigatc 5 are routers and NB1-NB5 are Node Bs. IP=X 
means that the IP address of the node is X. 
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In a general case, the RNC has n (where n> 1) connected Node Bs that are 
involved in the same DCH in soft handover mode. To select the DHO nodes for 
the DCH the RNC is adapted to retrieve from its above described topology 
database the full hop-by-hop routes between the RNC and each of the involved 
Node Bs. The retrieved routes form a *route tree*". Nodes where two or more 
routes join are called branching nodes (BNs). The RNC comprises means for 
selecting the best IDHO node(s) based on the nodes of the route tree, to only 
search for DHO nodes in the route tree is a restriction, which means that 
potential off-tree DHO nodes, which could be more optimal than on-tree DHO 
nodes, are disregarded. This restriction is a trade-ofif to limit the complexity of 
the selection mechanism. If tiie best of all potential DHO nodes (on-tree as well 
as oflf-tree nodes) were to be sought and an optimal route tree (independent of 
the individual routes) were to be created, this would involve calculation of 
Steiner trees, which is very complex and computation demanding. Thus, 
although not optimal, selecting the DHO node(s) from the on-tree nodes is 
considered good enough for this application at least in its basic form. 

Furthermore, when selecting the DHO node(s) the RNC is able to use either of 
two different basic approaches. The RNC is either adapted to choose among aU 
the on-tree DHO enabled nodes in the route tree or only among the DHO 
enabled nodes that are aware of the radio Unk properties of the DCH that the 
macro diversity concerns. The former approach allows more DHO enabled 
nodes to choose from, which in tum may result ia a more efiBcient macro 
diversity tree. However, when a DHO enabled node is selected that is not aware 
of the radio link properties of the DCH it is selected to combine, additional 
signaling is required to inform this DHO node of the DCH properties it needs to 
know in order to combine macro diversity legs of the DCH. In the latter 
approach the potential DHO nodes are restricted to RNCs and Node Bs that are 
responsible for at least one radio link towards the concerned UE. An S-RNC is 
inherently aware of the required DCH properties, a D-RNC is informed via 
RNSAP signaling and a Node B responsible for a radio link is informed via 
NBAP signaling. A Node B that is responsible for a radio link towards the UE 
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(i.e. a Node B that is included in the active set) is henceforth referred to as a 
"radio active Node B". A Node B that is not responsible for a radio link towards 
the UE (i!e. a Node B that is not included in the active set) is henceforth 
referred to as a "non-radio active Node B". Correspondingly, a DHO node that 
is responsible for a radio link towards the UE (i.e. a radio active Node B) is 
referred to as a "radio active DHO node". Other DHO nodes are referred to as 
"non-radio active DHO nodes". 

In the further description of the DHO node selection algoritiim it is assumed 
that the RNC selects tixe DHO node(s) among all tiie DHO enabled nodes in ttie 
route tree. However, the same algoritiim may be used to select the DHO nodes 
among tiie RNCs and tiie DHO enabled radio active Node Bs in tiie route tiree. 
That implies that only RNCs and DHO enabled radio active Node Bs are 
considered as potential DHO nodes instead of all RNCs and DHO enabled Node 
Bs in the route tree. 



A retrieved hop-by-hop route is represented by a list of IP addresses (the IP 
addresses of the intermediate routers and the destination Node B), 
accompanied by a number of metises for each hop. The IP address of tiie RNC 
is omitted, since it is not needed for the DHO node selection process. The 
metrics may include one or botii of a delay metiic and a generic cost metric 
(based on an arbitrary criteria). The metrics may be asymmetric, in which case 
one set of metrics is suppUed for each direction of a link, or symmetiric, in 
which case the same set of metrics is vaUd for both directions. In the 
illustrated example tiie metrics include botii a syimnetric delay metiic and a 
symmetric generic cost metiic according to one embodiment of the present 
invention. Table 1 shows the information tiiat could be included in the route 
information that the RNC retrieves in tiie example scenario (i.e. the scenario 
depicted in figure 5). 
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Route from the RNC to the Node B (NB) 1 




IP addresses (excluding the 
RNC) 


Symmetric generic cost 
metric for hop from 
preceding node 


Symmetric d 
metric for h 
from preced 
node 


1 


1 


1 


2 


1 


2 


8 


1 


3 
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Tablel 



With reference to the example illustrated in flgurc S. table 1 includes the 
routes with associated metrics received from the topology database. In this 
example symmetric delay and cost metrics are used. 

5 

To form a tree of the retrieved routes the RNC is adapted to see the routes as 
branches and to identify the branching nodes {of which there may be 1 
through n-1 where n is the number of branches). To identify the branching 
nodes, the RNC is arranged to start with the first IP address in the respective 
10 lists and then to step one address at a time to identify when a branch diverges. 

i.e. when its IP address differs from the IP address of the other branch(es). The 
IP address before a diverging IP address in the Ests represents a branching 
node. If two branches have no IP address at all in common, then the RNC is 
the branching node for these two branches. The procedure continues until all 
15 branching nodes have been identified. Figuie 6 shows the route tree that 

results from the example scenario of figure 5. 
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When all the branching nodes have been identified, their relative 
interconnections,, as well as their connections to Node Bs and the RNC, are 
identified. Identifying these connections in essence means that the RNC is 
adapted to create a simplified schematic tree consisting of only branching 
nodes. Node Bs and the RNC (i.e. intermediate routers are omitted). As is the 
case of the original route tree, this is still just a logical construction, 
essentially a data structure, in the RNC. It has yet no physical realization in 
the UTRAN. Flgare 7, illustrates a branching node tree corresponding to the 
route tree in figure 6 (i.e. the branching node tree resulting from the example 
scenario of figure S) and table 2 shows how the branching node tree could be 
represented as a data table. It should be noted that BN X means branching 
node number X. 



Stanching 
node (BN) 


IP address 


Uplink connection 


Downl 
connect 


BNl 
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BN2 
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BNl, IP^2 
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BN3 
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BN2, IP-4 


NB2, 1 
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BN4 
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BN2, IP=4 


NB4, II 
NB5, 11 



Table 2 
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An identified branching node may be an RNC, one of the Node Bs or an 
intermediate router. That is, it is not certain that a branching node is a DHO 
enabled node. However, for each branching node there is a corresponding 
potential DHO node. With a branching node as the starting point the RNC 
comprises means for selecting the best corresponding DHO node. To do this 
the RNC is arranged to make use of the cost metrics assigied to each hop and 
a Hst of the DHO enabled nodes in the RNS (represented by theh: IP addresses, 
i.e. the same IP addresses as are used to represent the nodes in hop-by-hop 
routes). In the inter-RNS case (i.e. when more than one RNS is involved) the 
RNC xnsQr also make use of lists of DHO enabled nodes in neighboring RNSs. In 
such case the RNC may be configured with these lists or it may retrieve them 
from the RNCs of the neighboring RNSs via signaling. In the DHO node 
selection example based on the example scenario of figure S the RNC and all 
the Node Bs in the route tree are assumed to be DHO enabled. 

The algorithm used for selecting a DHO node corresponding to a certain 
brandtiing node is simple. Starting from the branching node the RNC is able to 
accumulate the generic cost metric in each direction (i.e. in the direction of 
each branch in the original route tree including the uplink) from the branching 
node until a DHO enabled node (or the end of the path) is found. (If 
asjnnmetric generic cost metrics are used, the generic cost metrics has to be 
the accumulated roimdtrip from the branching node to the fotmd DHO enable 
node and back. If symmetric cost metrics are used it suffices to accumulate 
the generic cost metrics in one direction.) The RNC does this by using the 
original route tree - not the simpMed one. The DHO enabled node that was 
found with the smallest accumulated generic cost metric is selected as the 
DHO node corresponding to the concerned branching node. If the branching 
node is itself a DHO enabled node, it will of course be the selected DHO node, 
since it is obviously the best choice and the accumulated generic cost metric 
will be zero. 
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If more than one DHO enabled node is found with the same smallest 
accumulated generic cost metrics, the RNC should select the one that adds the 
least delay (in terms of accumulated delay metrics) to the original route from 
the concerned branching node to the RNC in accordance with an embodiment 
of the present invention. To calculate the added delay for a certain DHO 
enabled node the RNC comprises means for identi^g the node in the original 
route (i.e. the route from the concerned branching node to the RNC in the 
route tree) that is the closest to the DHO enabled node. The added delay is 
then calculated as the accumulated hop-by-hop delay metrics roundtrip from 
the identified closest node in the original route to the concerned DHO enabled 
node and back. If the added delays also are equal, the RNC is arranged to 
arbitraiy choose between the concerned DHO nodes in accordance with an 
embodiment of the presCTit invention. 

According to a further embodiment of the present invention, an alternative and 
simpler way for the RNC to select a DHO node out of two or more DHO enabled 
nodes that are found with the same smallest accumulated generic cost metrics 
is to arbitrarily select one of them. The resulting DHO node selections will be 
less optimal, but the advantage is that the RNC avoids the above described 
calculations of the added delays that compEcates the DHO node selection 
process. 

Returning now to the DHO node selection example based on the example 
scenario in figure 5, the DHO nodes corresponding to the identified branching 
nodes will be selected as follows. Since symmetric generic cost metrics are 
used in this example, the cost metric is accumulated in only a sin^e direction 
between a branching node and a potential DHO node. The DHO node 
corresponding to branching node R7 is NB4, for which the accumulated 
generic cost metrics from R7 is 4. All the other DHO enabled nodes in the 
route tree have greater accumulated generic cost metrics from this branching 
node. Similarly, the selected DHO node corresponding to the branching node 
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R5 is NB3, for which the accumulated generic cost metrics from R5 is 4. The 
selected DHO node corresponding to the branching node R4 is NB3 again, for 
which the accumulated generic cost metrics from R5 is 7. The selected DHO 
node corresponding to the branching node R2 is NBl, for which the 
accumulated generic cost metrics from R2 is 4. 

When the DHO node corresponding to each branching node has been selected, 
the selected DHO nodes are (logically) interconnected in the same way as their 
corresponding branching nodes {i.e. as indicated in the simplified schematic 
tree of branching nodes. Node Bs and tixe RNC) into a tree of DHO nodes. Node 
Bs and the RNC. This tree is denoted "DHO node tree". A DHO node may 
coincide with a Node B, an RNC or another DHO node. In such case the logical 
connection between the coinciding nodes disappear in the DHO node tree. like 
the route tree and thfe branching node tree, this DHO node tree is a logical 
construction in the RNC without physical realization in the UTRAN. Table 3 
and table 4 illustrate how the branching node tree table of the DHO node 
selection example, i.e. the branching node tree table of table 2, may be 
translated into a DHO node tree table. It should be noted that DHO(BNX) 
represents the selected DHO node corresponding to the branching node X. 
Figure 8 iUustrates the resulting DHO node tree (as a part of the DHO node 
selection example based on the example scenario in figure S). 
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Table 3 

From table 3 it can be concluded that DHO(BN2) and DHO(BN3) are one 
the same node, i.e. NB3. 
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Table 4 is the final DHO node tree table derived from the branching node tree 
table of table 2 (which is a part of the DHO node selection example based on 
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the example scsenario in figure 5). DHO(BN2) and DHO(BN3) have now been 
merged into a single DHO node, DHO(BN2,BN3). 

Fijgure 8 shows the DHO node tree resulting from the selection of DHO nodes 
5 corresponding to the branching nodes of the DHO node selection example 

based on the example scenario in figure 5, A data representation of the DHO 
node tree can be found in table 4. 

Checking that the maximum allowed delay is not exceeded falso referred to as 

10 the delay reduction phased 

When the DHO nodes are selected, the last step before instructing the UTRAN 
nodes to establish the route tree including the selected DHO nodes is to check 
that the maximum allowed transport delay between a Node B and the RNC is 
not exceeded. To do this, the connections in the DHO node tree are mapped 

15 onto the original route tree to form complete hop-by-hop routes. Figure 9 

illustrates this for the DHO node selection example based on the example 
scenario in figure 5, i.e. the DHO node tree of figure Sis mapped on the route 
tree of figure 6. The resulting data flows are shown with the thicker arrows in 
figure 9. 

20 

Hie RNC analj^es and adds the hop-by-hop delay, whidi is a part of the 
topology information for each Node B-RNC path, together to a complete 
transport delay for the new data path in both directions. For the uplink a 
default delay value for the frame combining procedure is also added by the 
RNC for eada DHO node in the path except the first one. 
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The delay calculated from the topology database may not be accurate enou^, 
but may still be used for relative delay measurements. Combining the relative 
delay measurements (using the delay metrics of the topology database^ with 
the more accurate Node ^chronisation measurements the result should be 
accurate enough. The Node Synchronization measurements are further 
described in 3QPPTS 25.402 VS. 1.0, "3«» Generation Partnership Project; 
Technical Specification Group Radio Access Network; Synchronisation in 
UTRAN Stage 2 (Release Sf and in 3GPP TS 25.427 V5.0.0, "3^ Generation 
Partnership Project; Technical Specification Group Radio Access Network; 
UTRAN lub/Iur interface user plane protocol for DCH data streams (Release 
5)". 

The Node Synchronisation procedure, which is a part of the DCH Frame 
Protocol (and other UTRAN user plane protocols), measures accurately the 
round trip delay from the RNC to a Node B and back. For increased stabiHty 
and accuracy the Node Synchronisation procedure may optionally be carried 
over dedicated high priority bearers. The Node Synchronisation procedure may 
be executed at any time, but in principle it should only have to be executed 
when the topology of the transport network has changed. The Node 
Synchronisation procedure is performed between the RNC and one or more 
Node Bs. The RNC sends a downlink Node Synchronisation control frame to 
one or more Node Bs (if the control frame is sent in the user plane of a DCH in 
soft handover mode, the control frame is subject to spUtting and will reach all 
the involved Node Bs). The downlink Node Synchronisation control frame 
contains certain time parameters. Each Node B that receives a downlink Node 
Synchronisation control frame responds with an uplink Node Synchronisation 
control frame containing certain time parameters. A reasonable alternative 
could be to execute the Node Synchronisation procedure every time a 
corresponding set of traceroute measurements has been carried out (when 
traceroute measurements are used). In ihe calculations combining tiie relative 
delay measurements (using ttie delay metiics of the topology database) witii 
Node Synchronisation delay measurements the foUowing notation is used: 
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10 



15 



20 



25 



Dns 



Dtop-oId-DL 



Dtop-old-UL 



Dtop-ncw-DL 



Dtop-ncw-UL 



Ndho 



Dcomb 



Dnew-path-DL 



DneW'path-UL 



The delay measured with the Node Synchronisation 
procedure. 

The downlixik transport delay of the original path (i.e. the 
route retrieved from the topology database) calculated 
from the topology database. 

The uplink transport delay of the original path calculated 
from the topology database. 

The dovntilink delay of the new path calculated from the 
topology database. 

The uplink delay of the new path calculated from the 
topology database. 

The number of DHO nodes in the data path (including the 
RNC if the RNC is one of the selected DHO nodes). 

The default delay value for frame combining. This value 
may depend on the number of frames that are combined, 
but henceforth it is assumed that the parameter has a 
fixed value that is independent of the number of combined 
frames. 

The estimated downlink delay of the new path as a result 
of combining the measurements based on the topology 
database and the Node Ssmchronisation measurements. 

The estimated uplink delay of the new path as a resxilt of 
combining the measvirements based on the topology 
database and the Node Synchronisation measurements. 



By combining the different delay parameters reasonably accurate values of the 
downlink and uplink delays of the new path may be calculated as follows: 

- 2(downlink hop delays of old path) 

Dtop-oid-ut = 2(uplink hop delays of old path) 
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- S(downlmk hop delays of new path) 
Dtop-new.uL = (Ndho - 1) X Dc^mb + S(uplink hop delays of new path) 

Dnew-path-OI. (Dtop-new-DL / Dtop-old-DL) X DnS 
5 Dnew-path-Xn« * (Dtop-new-UL / Dtop-oM-UI^ ^ DnS 

If symmetric delay metrics are used the calculations are slightly simplified. The 
delay values that should be compared with the maximum allowed delay are the 
values of Dne^-path-DL and Dnewp«th-UL. This means that if the measurements 
based on the topology data are somewhat inaccurate^ the maximum allowed 
10 value of the Dtop-new-OL and Dtop-nw-uL parameters miay be different for different 
data paths. For instance, a certain Dtop-new-Dt for one data path may cause the 
value to exceed the maximum allowed value, whereas the same Dtop- 
value for another data path may result in a value within the 

allowed range. 

15 

If either Dncw-path-DL or Dnew-path-uL exceeds the maximum allowed delay in the 
transport network (or a slightly lower delay threshold to provide a safety 
margin), the concerned path must be changed. There are difiFerent ways to do 
this with different levels of complexity (and performance). Ideally the DHO node 

20 selection should be restarted with new conditions to arrive at a new result, 

possibly with entirely or partly new DHO nodes. The goal should be to achieve 
data paths with acceptable delays with as small increase as possible in the 
overall accumulated cost metrics compared to the first DHO node tree. 
However, another important goal is to keep the algorithm simple and 

25 computation efScient. Therefore the DHO node selection is preferably not 

restarted. Instead the concerned data path is modified in order to decrease its 
delay down to an acceptable level. 

The way to modify the data path is to remove one or more DHO nodes j&rom the 
30 path, until the path delay is smaller than the maximum allowed value. By 



35 



removal of a DHO node from a path is meant that the concerned data flow 
bypasses the DHO node. The removed DHO node may remain in the path (if it 
is included in tiie original route of the Node B of the path), but its DHO 
functionaHty is not applied to the concerned data flow. If the data flow had to 
make a detour to reach the DHO node, the DHO node will not remain in the 
path after its removal. 

Which DHO node(s) should be removed? According to embodiments of the 
present invention, there are several methods for stepwise removal of DHO 
nodes in a path. They differ in complexity and efficiency. In all but the last 
method (which is fundamentally different from the others) the required path 
delay reduction (calculated in the route tree using data from the topology 
database) may preferably be calculated before the path delay reduction method 
is started. 

If the dovmUnk path delay is too large, the required downlink delay reduction 
(in terms of delay metrics) is Dred-oL = Dtop-new-oL - Dmax x D^p^om-dl / Dm, where 
Drcd-DL is the required downlink del^ reduction and Dmax is the maximum 
allowed delay. If the uplink path delay is too large, the required uplink delay 
reduction (in terras of delay metrics) is D^.vl - T>t«^T^vL - D«ax x DtoiM,id-uL / 
Dns, where Dred-uL is the required uplink delay reduction. 

If more than one of the paths (i.e. macro diversity legs) have too large delays, 
the RNC should perform the delay reduction through DHO node removal for 
the path vdth the greatest delay first. The removal of DHO nodes from this 
path may reduce the delay of other paths too (e.g. if a DHO node was removed 
from a part of the path that represents a combined data flow). Thus, before 
starting the delay reduction for the next path the RNC should check whether 
the path delays have changed as a result of delay reduction measures for 
previous paths. 
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Below are a few patii delay reduction methods based on DHO node removal 
with reasonable relation between efficiency and complexily. In case the RNC 
(i*e, the S-RNC) is a DHO node?, it is excluded from the DHO nodes that can be 
5 removed. Hii^ applies to all the methods. The methods assume that there is at 

least one DHO node other than the RNC in the concerned path. This is a safe 
assumption, since a path with the RNC as the only DHO node (i.e, a path 
according to the current UTRAN macro diversity principles) could not have a 
too large delay, unless the transport network is erroneously designed or 
10 configured. Should such a case still arise, then the RNC should assume that 

the delay measurements are incorrect and use the path anyway. All the 
methods caa be applied to the downlink and the uplink separately, but the 
methods are to the most part described independently of downlink and uplink. 



15 When a DHO node is removed from the path, the path delay normally 

decreases and the cost in terms of accumulated generic cost metrics of the 
path normally increases. Regarding the delay, the delay reduction for a certain 
path is what matters* If a removed DHO node remains in the path (although it 
no longer applies its DHO functionality to the concerned data flow), the 

20 downlink path delay is unaffected, whereas the uplink path delay is reduced 

by a frame combining delay (unless the removed DHO node was the 
hierarchically highest DHO node in the path). In all other DHO node removal 
cases the path delay is reduced. Regarding the generic cost metrics, what 
matters is the increase in the total generic cost metrics for both directions of 

25 the concerned DCH {Le. including both directions of all the macro diversity 

legs). In almost all DHO node removal cases the total generic cost metrics is 
increased, but in certain extreme and unlikely scenarios it may be unaffected 
or even decreased as a result of a DHO node removal. A cost metric decrease is 
represented as a negative cost metrics increase in the calciJarions. 
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In several of the delay reduction methods the RNC needs to calculate the 
potential path delay reduction (in terms of delay metrics) and/or cost increase 
(in terms of the generic cost metrics for the whole DCH) that would result from 
the removal of a certain DHO node from the path. 

To calculate the potential path delay reduction the RNC first identifies the nodB 
that is the closest to the concerned DHO node out of the nodes in the ori^al 
route (i.e. the route retrieved from the topology database) of the RNC-Node B 
path (or Node B-RNC path) whose delay is to be reduced. This may be a 
branching node (in the original route tree), but it may also be the DHO node 
itself (which may or may not be a branching node). The potential downlink 
path delay reduction (in terms of delay metrics) is calculated as the 
accumulated hop-by-hop delay metrics in the roundtrip from the identified 
closest node (in the original route) to the DHO node and back to the identified 
closest node again. The potential uplink path delay reduction is calculated m 
the same way with the addition of a frame combining delay, unless tiie DHO 
node is the hierarchically highest DHO node in tiie path. 



The calculation of the potential cost increase is more complicated. There are 
four different cases to consider 

1. Before its removal, the DHO node applied its splitting and combining 
functionality to tiiree or more data flows which means that after the removal 
the DHO node will still apply its DHO functionality to at least two data flows. 

2. Before its removal, tine DHO node appUed its spUtting and combining 
functionaKty to two data flows which means that after the removal the DHO 
node wUl not apply its DHO fUnctionaHfy to any data flow. The DHO node is 
included in one and only one of the original routes i.e. \he optimal routes in 
the route tree of the two concerned data flows. 
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3. Before its removal, the DHO node applied its splitting and combining 
functionality to two data flows which means that after the removal the DHO 
node will not apply its DHO functionality to any data flow. The DHO node is 
included in the original routes (i.e. the optimal routes in the route tree) of both 

5 the concerned data flows. 

4. Before its removal, the DHO node applied its splitting and combining 
functionality to two data flows which means that after the removal the DHO 
node will not apply its DHO functionality to any data flow. The DHO node is 
not included in the original route (i.e. the optimal route in the route tree) of 

10 any of the concerned data flows. 



In case 1, the RNC chooses the data flow from which the concerned DHO node 
potentially will be removed i.e. the data flow whose path delay is to be reduced. 
The RNC then identifies the node that is the closest to the concerned DHO 

15 node out of the nodes in the original route based on the route tree of the 

chosen data flow. The potential cost increase is then calculated as the 
accumulated hop-by-hop generic cost metrics roundtrip from the identified 
node to the next uplink DHO node in the path (or the RNC if there is no uplink 
DHO node) and back minus the accumulated hop-by-hop generic cost metrics 

20 roundtrip jfirom the identified node to the concerned DHO node and back. 

These calculations could be performed when delay reduction is required or in 
advance during the DHO node selection process (during which the RNC 
anyway performs hop-by-hop accumulations from branching nodes to potential 
DHO nodes). 

25 

In the second case, the RNC chooses the data flow for which the concerned 
DHO node is not included in the original route (as seen in the route tree). The 
RNC then performs the same node identification and cost increase calculation 
as described for case 1. 
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In the third case, the RNC arbitrarily chooses one of the two data flows. The 
RNC then performs the same node identification and cost increase calculation 
as described for case 1 . In this case the RNC could equally well skip the node 
identification and simply calculate the cost increase as the accumulated hop- 
5 by-hop generic cost metrics roundtrip from the concerned DHO node to the 

next uplink DHO node in the path (or the RNC if there is no uplink DHO node) 
and back. 

In the fouiili case, the RNC performs the node identification and cost increase 
10 calculation described for case 1 for both data flows. To arrive at the total cost 

increase (which in this case may be negative) the RNC then adds together the 
cost increases calculated for both data flows and subtracts the accumulated 
hop-by-hop generic cost metrics roundtrip from the concerned DHO node to 
the next uplink DHO node in the path, or the RNC if there is no uplink DHO 
15 node, and back. 

Another way to calculate the potential delay reduction is to tentatively remove 
the concerned DHO node, recalculate the entire path delay and subtract it 
from the path delay calculated before the DHO node removal. The potential 
20 cost increase can be calculated in a similar way by accumulating the hop-by- 
hop generic cost metrics in both directions for the entire DCH (i.e, for all macro 
diversity legs) before and after the tentative DHO removal. 

According to embodiments of the present invention, there are nine different 
delay reduction methods adapted to be implemented in the RNC; 
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1. In this method, the RNC first calculates the potential delay reduction 
and cost increase (as described above) for each DHO node that could be 
removed from the path. It then chooses to remove the DHO node for which the 
potential cost increase/delay reduction ratio is the smallest. If this is not 
enough to bring down the path delay to an acceptable level, the method is 
repeated for the modified path. 

2. In this method, the RNC first calculates the potential delay reduction 
and cost increase (as described above) for each DHO node that could be 
removed from the path. It also calculates the total accumulated generic cost 
metrics for the DCH (i.e. for the whole route tree). The RNC then chooses to 
remove the DHO node for which the greatest value results from the calc\ilation 
of {potential delay reduction) / (total path delay before DHO node removal) - a 
X (potential cost increase) / (cost for the whole DCH in both directions before 
DHO node removal), where a is a configured value, e.g, 2, If this is not enough 
to bring the down the path delay to an acceptable level, the method is repeated 
for the modified path. 

3. In this method, the RNC first calculates the potential cost increase (as 
described above) for each DHO node that could be removed from the path. It 
then chooses to remove the DHO node for which the potential cost increase is 
the smallest. If this is not enough to bring the down the path delay to an 
acceptable level, the method is repeated for the modified path. 

4. In this method, the RNC first calculates the potential delay reduction 
(as described above) for each DHO node that could be removed from the path. 
It then chooses to remove the DHO node for which the potential delay 
reduction is the greatest. If this is not enough to bring the down the path delay 
to an acceptable level, the method is repeated for the modified path. 
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5. In this method, the RNC removes the first DHO node in the path in the 
direction from the Node B to the RNC, excluding DHO nodes that are included 
in the original RNC-Node B route retrieved from the topology database. The 
resulting delay reduction is calculated and if it is not enou^, the method is 
repeated for the modified path. If it is only the uplink path delay that needs 
reduction and there is no DHO node in the path that is not included in the 
original route, then a DHO node that is inchided in the original route (except 
the BINC) m^ be removed in order to reduce the uplink patii delay by the 
frame combining delay. 

6. In this method, the RNC first calculates the potential delay reduction 
(as described above) for each DHO node that could be removed from the path. 
It then chooses to remove the DHO node for which the potential delay 
reduction is the smallest, but stiU greater than (or equal to) the required delay 
reduction. If no DHO node fulfilling this criterion can be found, the RNC 
chooses to remove a DHO node according to any of the criteria in methods 1 
through 5. If the DHO node removal is not enough to bring the down the path 
delay to an acceptable level, the method is repeated for the modified path. 

7. In this method, the RNC tries to leverage the fact that a DHO node 
removal may decrease the delay of more than one path. Thus, it first checks 
whether there is one or more other paths (otiier than the concerned path, the 
path with the largest delay reduction requirement that is) that also have too 
large delays. If so, the RNC identifies the DHO nodes that are common for the 
concerned path and one or more of the other paths needing delay reduction 
(and which DHO node is not included in the any of the original routes for the 
concerned Node Bs). Among these DHO nodes the RNC chooses to remove one 
according to any of the criteria in methods 1 through 5. If no such common 
DHO node can be found, the RNC chooses to remove a DHO node according to 
any of the criteria in methods 1 through 5. Alternatively, the RNC can identify 
the DHO nodes that are common for the concerned path and that of the other 
paths that needs the largest delay reduction (but which DHO node is not 
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included in any of the original routes for the concerned Node Bs) and remove 
one of them (according to any of the criteria in methods 1 through 5). If the 
concerned path does not have any such DHO node in common with that of the 
other paliis that needs the largest delay reduction, the RNC repeats the 
procedure with that of the other paths that needs the second largest delay 
reduction, and so on. Again, if the concerned path has no DHO node in 
common with any of the other paths needing delay reduction, the RNC chooses 
to remove a DHO node according to any of the criteria in methods 1 through 5. 
If this is not enough to bring the down the path delay to an acceptable level, 
the method is repeated for the modified path. 

8. In this method, the RNC removes all the DHO nodes (except the RNC) 
from the path. That is, the original route is restored and the RNC is the only 
DHO node in the modified path. 

9. In this method the RNC considers the dday increase and the 
TnayiTmim delay threshold already during the DHO node selection process. 
A£t^ retrieving the routes of the macro diversity legs jfrom the topology 
database the RNC calculates the accumulated delay metrics for both directions 
for each route. Hie results are compared with the maximum allowed path 
delay and the delay metrics maj^ to the maximum delay is calculated for 
both directions for each route in, e.g. in the way described above. 

Then the formation of the route tree, the identification of the branching nodes 
and their relative interconnections are performed in the same way as described 
above. The subsequent step, i.e. the actual selection of the best DHO node 
corresponding to each branching node, is, however, enhanced in that the delay 
metrics are considered in addition to the generic cost metrics. 

When the RNC calculates the accumulated hop-by-hop generic cost metrics 
from a certain branching node to the DHO enabled nodes in the route tree, it 
also keeps track of the hop-by-hop delay metrics. When the DHO enabled node 
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with the smaUest accumulated generic cost metrics (measured from the 
branching node) is found, the RNC checks that the resulting added delay for 
each affected route (in each direction) is not greater than the remaining delay 
metrics margin to the maximum delay. The affected routes are those (original 
routes) that pass througli the concerned branching node. The added delay in 
the dovmlink direction for a route is calculated as the accumulated hop-by-hop 
delay metrics roundtrip from the tentatively selected DHO node to the closest 
node that is included in the concerned route and back. The added delay in the 
uplink direction is calculated in the same way with the addition of a frame 
combining delay, unless this is the first DHO node to be selected for the 
concerned route (in which case no frame combining delay is added). 



To integrate the calculation of the added delay with the cost metrics 
accumulation the RNC is arranged to do as foUows, In its search for the best 
DHO enabled node corresponding to a certain branching node, each time the 
RNC "steps" away from a branching node (including the concerned branching 
node) where at least one of the affected routes divert from path that the RNC is 
"stepping" in the route tree, the RNC starts to accumulate the hop-by-hop 
delay metrics (in both directions) and continues to do so all the way to the 
DHO enabled node. Subsequently, when the RNC has tentatively selected a 
DHO node corresponding to the concerned brandling node, the RNC has 
already (during the "stepping" process) calculated the accumulated hop-by-hop 
delay metrics roundtrip from the tentatively selected DHO node to the closest 
node included in each of the affected routes. Thus, the RNC is arranged to 
immediately check whether the remaining delay margin would be exceeded for 
any of the affected routes, if the tentatively selected DHO node were to be 
finally selected. 



The RNC may also combine the (possibly somewhat inaccurate) delay metrics 
from the topology database with the more accurate delay measurement results 
from the Node Synchronisation procedure (similar to what is described above) 
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in order to calculate more accurate dday margins. The initial d^ay mar§pns 
(measured in terms of delay metrics from the topology database) for the 
downlink and the uplink could then be calculated as follows: 

Dmarg-DL = Dtop-oW-DL {Dmax / DnS — 1) 
Dtop-oW-UL X (Dnuuc / Dms - 1) 

where Dmarg-oL and Dm^-m are the delay margins for the downlink and uplink 
respectively, Dmax is the maximum allowed delay and Dto|W)M-Di, Dtop^.M-uL and 
Dns are the same as previously defined. 

10 In order for this DHO node selection process with integrated delay checks to 

work well the RNC should start the DHO node selection process with the 
branching nodes in the lowest layer of the branching node hierarchy and 
continue with the branching nodes of the next hierarchical l^er etc. 

15 The consequences of the integrated d^y checks for a tentativdy selected DHO 
node can be divided into three different cases, depending on the nimiber of the 
affected routes for which the remaining del^ margui is not exceeded. 

If the remaining delay margin is not exceeded for any of the affected routes, the 
20 RNC can safely select the DHO node. The RNC then reduces the remaining 

delay mar^ for the affected routes with their respective added delays and 
continues the DHO node selection process with the next branching node (if 
any). 

25 If the remaining delay margin for one or more of the affected routes is 

exceeded, but lliere are at least two affected routes for which the remaining 
delay margin is not exceeded, then the DHO node can be selected for those of 
the affected routes that passed the delay check, but not for the othear(s). The 
RNC then notes that the data paths of the macro diversity legs whose routes 
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did not pass the delay check should bypass the selected DHO node. This note 
should make, sure that this circumstance is reflected in the subsequently 
created DHO node tree. Rnalljr the RNC reduces the remaining delay margin 
for the affected routes that passed the delay check vith ttieir respective added 
delays and continues the DHO node selection process with the next branching 
node (if any). 

If the remaining delay mar^ for one or more of the affected routes is exceeded 
and only one or none of the affected routes passed the delay check, then no 
DHO node at all is selected for the concerned branching node. In this situation 
it would be possible for the RNC to check whether the second best DHO 
enabled node (or any other potential DHO node) could be selected, but the 
probabiUty of finding one for which at least two of the affected routes pass the 
delay check is very low. Hence, in order not to complicate the DHO node 
selection process further the RNC might as well accept that no DHO node is 
selected for this branching node. The RNC notes this and makes sure ti:iat it is 
reflected in the subsequentiy created DHO node tree. The RNC tiien continues 
the DHO node selection process with the next branching node (if any). 

Returning again to tiie DHO node selection example based on the example 
scenario in figure 5, which now continues with the delay reduction phase 
(since delay reduction method number 9. i.e. the above described delay checks 
mtegrated in the DHO node selection process, is not used in tiiis example). For 
the purpose of illustration (i.e. illustirating two alternative delay reduction 
methods) both delay reduction metiiod number 5 and delay reduction method 
number 6 will be applied. 

First it is assumed that delay reduction method number 5 is appUed witii a 
default frame combining delay value of 3. As previously mentioned tiie 
maximum allowed value of the delay measurement value based on the topology 
data (i.e. the delay metiics in the route tiree) can differ between different data 



46 

paths, because the delay metrics in the topology database may be somewhat 
inaccurate. However, in this example it is assumed that the tnaximum allowed 
accumulated delay metrics is 45 for all the data paths. 



5 As can be derived from figure 9 the data path of NBl has a downlink delay of 

6 and the same value for the uplink delay. The data path of NB2 has a 
downUnk delay of 34 and an uplink delay of 37. The data path of NB3 has a 
downlink delay of 24 and an uplink delay of 27. The data path of NB4 has a 
downlink delay of 45 and an uplink delay of 5 1 . The data path of NB5 has a 

1 0 downlink delay of 55 and an uplink delay of 6 1 . 

Consequently the uplink delay for the data path of NB5 must be reduced by a1 
least 61 - 45 = 10 and its downlink delay must be reduced by at least 55 - 45 
10. Similarly the uplink delay for the data path of NB4 must be reduced by at 
15 least 51 - 45 = 6. 



The delay reduction method starts with the data path with the greatest delay 
reduction needs, i.e. the data path of NB5 in this example. According to delay 
reduction method number 5, the first DHO node in the path in the direction 

20 from the Node B to the RNC should be removed first (excluding DHO nodes 

that are included in the original RNC-Node B route retrieved from the topology 
database). This means that DHO node NB4 is removed from the data path of 
NB5 in the first step. The resulting modified DHO node tree table and DHO 
node tree are shown in table 5 and figure lO. The resulting potential data 

25 flows in the route tree are depicted in figure 11. 



DHO node 


IP address (and node 


Uplink 


Dow 




name) 


connection 


connc 



47 



DHO(BNl) 


8 (NBl) 


RNC 


DHO{E 








IP=] 








(BNl r 








i/f 


DHO(BN2, 


10 (NB3) 


DHO(BNl), 


NB2, ] 


BN3) 




IP=8 


NB4, i: 








NB5, i: 








(NB3i 











Table 5. Hie modified DHO node tree table after the first step of the delay 



reduction method number 5. 

This first step reduced the uplink delay of the data path of NB5 by 13 and 
the downlink delay by 10. This is enou^ for Uie downlink delay, but the 
upKnk delay has to be reduced by another 3 units. Thus, according to the 
delay reduction method number 5 the next DHO node in the Node B to 
RNC direction of the data path of NB5 is removed. This means that the 
DHO node NB3 is removed firom the data path of NB5 in the second step. 
The resulting modified DHO node tree table after the second step of the 
delay reduction method number 5 is shown in table 6 and the DHO node 
tree is shown in figure 12. The resulting potential data flows in the route 
tree are depicted in figure 13. 
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The second step reduced the uplink delay of the data path of NB5 by 21 (and 
the dovmlink delay by 18). This is enou^ and the delay reduction for the path 
of NB5 is thereby finalized. Then the delay reduction method may be applied to 
the data path of NB4. As previously stated, the uplink delay of the data path of 
NB4 must be reduced by 6 units whereas the downlink delay needs no 
reduction. However, the removal of NB4 as a DHO node of the data path of 
NB5 means that NB4 no longer acts as a DHO node for the data path of NB4 
either. Consequently, the uplink delay of the data path of NB4 has already 
been reduced by 3 units. Remaining to be reduced are another 3 units. 
According to the delay reduction method number 5, the first DHO node in the 
Node B to RNC direction should be removed from the data path of NB4. Thus, 
in the third step the DHO node NB3 is removed from the data path of NB4. The 
resulting modified DHO node tree table and DHO node tree after the third step 
of the delay reduction method number 5 are shown in table 7 and figure 14. 
The resulting potential data flows in the route tree are depicted in figure 15. 
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Table 7. 



Thus the thuxi step reduced the uplink delay of the data path of NB4 by 2 1 
(and the downlink delay by 18). This is enough and consequently the delay 
reduction for the entire DCH i.e. for all data paths is thereby finalized. 

If instead delay reduction method number 6 would have been used in the 
example, the result would have been different. In the foUowing, the delay 
reduction is restarted and the delay reduction method number 6 is used. 



According to the delay reduction method number 6, according to one 
embodiment of the present invention, the DHO node for which the potential 
delay reduction is the smaUest, but still greater than (or equal to) the required 
delay reduction, sho\ild be removed first. Starting again with the data path of 
NB5 (which is the data path that needs the greatest delay reduction) the 
potential delay reductions for the three DHO nodes are as follows. The removal 
of DHO node NB4 would reduce the uplink delay of the data path of NB5 by 13 
and the downlink delay would be reduced by 10. The removal of DHO node 
NB3 would reduce the uplink delay of the data path of NB5 by 2 1 and the 
downlink delay would be reduced by 18. Finally, the removal of DHO node NBl 
would reduce the uplink delay of the data path of NB5 by 6 (no frame 
combining delay would be saved since NBl is the hierarchically highest DHO 
node in the path) and the downlink delay would be reduced by 6. 

Hence, because the required delay reduction for the data path of NB5 (as 
previously mentioned) is 16 in the uplink and 10 in the downlink, DHO node 
NB3 is the only one, whose sole removal is enough to reduce both the uplink 
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and downlink delays of the data path of NB5 to acceptable values. 
Consequently DHO node NB3 is removed from the data path of NB5 in the first 
step of delay reduction method number 6. The resulting modified DHO node 
tree table and DHO node tree after the first step of delay reduction method 
number 6 are shown in table 8 and figure 16. The resulting potential data 
flows in the route tree are depicted in figure 17. 
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Table 8. The modified DHO node tree table after the first step of delay 



reduction method number 6- 

After this step the delay reduction for the data path of NB5 is finalized. Then 
the delay reduction method may be applied to the data path of NB4. As 
previously stated the uplink delay of the data path of NB4 must be reduced by 
6 units (whereas the downlink delay needs no reduction)- However, the 
removal of NB3 as a DHO node in the data path of NB5 has affected the delay 
of the data path of NB4 too. The reason is that the data flow constituting the 
part of the data path of NB5, from which DHO node NB3 was removed, is 
combined with the data flow of NB4, Hence, when DHO node NB3 was removed 
from the data path of NB5, it was also removed from the data path of NB4. The 
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uplink and downlink delay reductions are the same for the data path of NB4 as 
they were for the data path of NB5, i.e. an uplink delay reduction of 21 and a 
downlink delay reduction of 18. This is more than required and thus the delay 
reduction for the data path of NB4 is also finalized. Consequently the delay 
5 reduction for the entire DCH (i,e. all the data paths) is finalized. 

The final DHO node tree is then the basis for instructions to the selected DHO 
nodes and the establishment of transport bearers. 



10 A DHO Node Selection Algorithm for Cascaded Base Stations 

It should be noted that the following description of the DHO Node Selection 
Algorithm for Cascaded Base Stations is not within the scope of the claims but 
is disclosed to give a better understanding of the invention. 

15 In a UTRAN topology with cascaded base stations the base stations are 

interconnected in a sequence. That is, the path from the RNC to the last base 
station in a sequence of cascaded base stations passes throu^ all the other 
base stations in the sequence. A RNC may connect several sequences of 
cascaded base stations, each of which having no part of its data path in 

20 common with the other sequences. Cascaded base stations may also be 

combined with a UTRAN tree topology. In such case one or several branches of 
a tree may comprise cascaded base stations. Yet a variation of the cascaded 
base stations topology is to interconnect the cascaded base stations and the 
RNC in a loop, such that both ends of the sequence of cascaded base stations 

25 are connected to the RNC. The purpose of such a loop is to provide transport 

path redundancy in case a link in the loop is temporarily malfunctioning. 
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The hierarchical macro diversity scheme, wherein the macro diversity 
functionality is distributed to the Node Bs, is most beneficial in a UTRAN 
topology with cascaded Node Bs. It may hence be useful to design a DHO node 
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selectioa algorithm that is tailored for cascaded Node Bs. Such a DHO node 
selection algorithm could be made very simple, but could only be used for 
macro diversity among Node Bs within a single sequence of cascaded Node Bs. 
The DHO node for legs involving Node Bs from different sequences of cascaded 
Node Bs would have to be selected using a more generic algorithm e.g. the one 
described above. The simplest solution would be to choose the RNC as the 
DHO node for such macro diversity legs. Macro diversity between legs involving 
one Node B in a sequence of cascaded Node Bs and another Node B located in 
another UTRAN tojxjlogy would be handled in the same way. 

For the macro diversity legs involving only (DHO enabled) Node Bs belonging to 
the same sequence of cascaded Node Bs the DHO nodes is selected as foUows. 
Of the radio active Node Bs, i.e. the Node Bs that are responsible for the radio 
link part of a macro diversity leg. the one that is the closest to the RNC in 
terms of number of hops is selected as the DHO node for its own data flow. i.e. 
the data flow across the radio interface, and the data flow to and from the 
radio active Node B that is the next closest to the RNC. The active node that is 
the next closest to the RNC is selected as the DHO node for its own data flow 
and the data flow to and from the next radio active Node B (as seen in the 
direction from the RNC). This algorithm is repeated until the last radio active 
Node B is reached (i.e. the radio active Node B that is the furthest away from 
the RNC in terms of number of hops). This last radio active Node B is the only 
one that wiU not act as a DHO node. 

This algorithm requires that all the Node Bs in the sequence of cascaded Node 
Bs (or at least the radio active Node Bs in the sequence) are DHO enabled. If 
not all the Node Bs in the sequence of cascaded Node Bs are DHO enabled, the 
algorithm may be extended with the following rule. If one of the radio active 
Node Bs, except the one furthest away from the RNC, cannot act as a DHO 
node because it is not DHO enabled, it is replaced (as a DHO node) by the next 
available DHO enabled node in the direction of the RNC. This next available 
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DHO enabled node may be another radio active Node B, a non-radio active 
Node B, the RNC or even a future type of RNL node {e.g. a specialised DHO 
node). However, if the DHO node selection algorithm is designed to select DHO 
nodes only from the radio active Node Bs (and the RNC) then a non-radio 
active DHO node or a future type of RNL node cannot replace a non-DHO 
enabled radio active Node B as a DHO node. 



For these simple topologies the topology information may be manually or semi- 
automatically configured in the RNC (but automatic mechanisms are of course 
10 possible also in this case). It is even possible to configure the RNC only with 

information about the sequential order of the cascaded Node Bs, disregarding 
the other transport network related information. This is all the RNC is required 
to know in order to select DHO nodes in this spedlal case. 

This DHO node selection algorithm is not only appUcable to Node Bs that are 
15 strictiy cascaded on the IP level or AAL2 level. It may also be appHed to a 

sequence of cascaded Node B sites, where each Node B site include a Node B 
co-located with a router. In such a scenario, the Node Bs would, from a strict 
network topology perspective, be regarded as interconnected in a tree 
structure. However, due to the potentially low cost and low delay of the intra- 
20 site link between the router and the Node B, using these Node Bs as DHO 

nodes would be almost equally beneficial as using the strictiy cascaded Node 
Bs as DHO nodes. To use such Node Bs as DHO nodes the RNC should be 
configured with the sequential order of the Node Bs (i.e. strictiy speaking the 
sequential order in which the Node B sites are interconnected), disregarding 
25 that the network topology strictiy is a tree structure. Then tiie above described 

algorithm (for selection of DHO nodes in a cascaded Node B network topology) 
could be used as it is. It would of course also be possible to use this method 
when strictiy cascaded Node Bs and Node Bs co-located with routers are mixed 
in the same sequence. 

30 



Using off-tree DHO enabled nodes in the DHO selection algorithm 
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In certain cases the DHO node, selection process could arrive at more optimal 
DHO node trees, if off-tree DHO enabled nodes (i.e. DHO enabled nodes that 
are not included in the ori^al route tree) could also be selected as DHO 
nodes. This would be particularly useful if the UTRAN transport network has a 
meshed topology, but in certain cases it would be beneficial also in transport 
networks wittx tree topology or hybrids of tree topology and cascaded base 
stations. An example of such a case is when the off-tree DHO enabled node is a 
Node B that is co-located with a router that is a branching node in the route 
tree. Such a Node B would be a beneficial choice of DHO node, despite its off- 
tree location. (Even though the Node B is co-located with an on-tree router, it 
is regarded as an off-tree node, because from a pure network topology 
perspective the Node B is located one hop scway firom the co-located router.) 

To enable selection of off-tree DHO enabled nodes the RNC could maintain 
additional information for eadti node (at least each non-DHO enabled node) in 
its topology database. For each node this additional information would indicate 
the closest DHO enabled node (represented by an IP address or an ATM 
address) and the accumulated delay and generic cost metrics (in both 
directions) for the path between the concerned node and its closest DHO 
enabled node. For a node that is itself a DHO enabled node this associated 
information would either not be present or indicate the node itself as the 
closest DHO enabled node with the accumulated delay and g«ieric cost 
metrics both set to zero. This information may also be kept in a separate 
database. 

To create this information when the traceroute method is used the RNC keeps 
a separate database including each router in the RNS. The RNC notes the 
destination Node B as the closest DHO enabled node for each router in the 
route, when a traceroute measurement is performed. The information is 
potentially inserted in the separate database. If a closest DHO enabled node is 
already stored for a router in the separate database, then the destination Node 
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B replaces the stored DHO enabled node as the closest DHO enabled node only 
if the accumulated generic cost metrics from the router to the destination Node 
B is smaUer than the accumulated generic cost metrics from the router to the 
already stored closest DHO enabled node. This traceroute based method to 
locate the ddsest DHO enabled node for each router in the RNS works weU for 
cascaded base stations and tree topology UTRANs, but it does not Tvork weU if 
a meshed transport network topology is used. 

When performing the calculations of accumulated generic cost metrics, as 
described above in conjunction with the DHO node selection algorithm, for 
DHO node selection or for calculation of potential cost increase (as a result of a 
potential DHO node removal), it must be taken into account a fundamental 
difference between off-tree and on-tree DHO enabled nodes. For an on-tree 
DHO enabled node there will always be at least one data flow to and from the 
node's uplink interface, whether the node is selected as a DHO node or not. 
However, this is not the case for an off-tree DHO enabled node. If the off-tree 
DHO enabled node is not selected as a DHO node, there wiU be no data flow to 
or from the node in any direction. Thus, the data flows between an off-tree 
DHO node's uplink interface and the ori^nal route tree must be considered in 
the calculations, since it represents a cost increase resulting from the selection 
of the off-tree node as a DHO node. Hence, an off-tree DHO enabled node is 
not likely to be selected, unless the accumulated generic cost metric from the 
corresponding branching node to the off-tree DHO enabled node is veiy low, 
Uke e.g. if the off-tree DHO enabled node is a Node B that is co-located with the 
concerned branching node. 

When selecting the DHO node corresponding to a certain branching node, the 
RNC should consider the DHO enabled node indicated in the topology 
information as the DHO enabled node closest to the branching node in 
addition to the on-tree DHO enabled nodes. 
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l?«.^ltwiiion of a DHO node tree 

When the RNC has selected which of the Node Bs that should comprise DHO 
nodes, the RNC uses Node B Application Part (NBAP) (and Radio Network 
Subsystem AppUcation Part (RNSAP) and the inter-RNS case) to instruct the 
DHO nodes located in Node Bs (or in the D-RNC) and other affected Node Bs so 
that the intended macro diversity is estabUshed. The instructions include IP 
addresses and UDP ports (or ATM addresses and SUGR references) to direct 
the data flows between the mvolved nodes. Examples of other instructions that 
may be included are QuaHty of Service (QoS) information for the inter-Node B 
transport bearers, timing instructions for the uplink combining function and 
time indications for activation of the DHO instructions. 

It should be understood that the method using instructions or other means to 
establish the macro diversity in accordance with the (lo^cal) DHO node tree is 
independent of the method that is used to obtain or create the (logical) DHO 
node tree. 



If a transport network control plane protocol is used, the selected Node Bs wii 
DHO functionaHly use this control plane protocol to estabKsh the inter-Node 
transport bearers according to the instructicms from the RNC. 



To estabUsh a hierarchical macro diversity structure the selected DHO nodes 
need to be instructed so that they know where to send split downlink flows 
and what uplink flows to combine. These DHO node instructions are based on 
the DHO node tree that is the outcome of the DHO node selection process. 
Every time the DHO node tree changes (due to addition or removal of macro 
diversity legs) ail the affected nodes (both DHO nodes and non-DHO Node Bs) 
need new instructions. Instructions are needed also when DCHs are added or 
removed from all macro diversity legs. DHO nodes may also need QoS 
instructions when DCHs are modified in a way that the QoS of their transport 
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bearers have to be changed. The affected nodes may range from a single 
Node Bs in the DHO node tree. No signaling is required when only the F 
affected. 



In order to direct the DCH data flows in accordance with the DHO node tree 
the RNC must provide the involved Node Bs with the IP addresses and UDP 
ports (in an IP UTRAN) or ATM addresses and SUGR parameters {in an ATM 
UTRAN) that they need to estabUsh the inter-Node B transport bearers. If a 
transport network control plane protocol is used, the Node Bs handle this 
transport network control plane signaling between themselves and 
intermediate routers or AAL2 switches for ititer-Node B transport bearers. 
However, there is no inter-Node B RNL signaling. 

To direct a transport bearer between a DHO node or a leaf Node B (in the DHO 
node tree) and a hierarchicaUy higher DHO node or the RNC in an IP UTRAN 
without a transport layer control plane protocol, the RNC conveys to the DHO 
node or leaf Node B the destination IP address and UDP port to be used in the 
uplink direction of the transport bearer. That is, in essence, unless the 
hierarchically higher node is the RNC itself, the RNC replaces an IP address 
and a UDP port of the RNC (that would have been included in the messagp if 
distributed macro diversity had not been used) by an IP address and a UDP 
port of the hierarchically hi^er DHO node. The receiving node returns the 
destination IP address and UDP port to be used in the downlink direction of 
the transport bearer. 



In an ATM UTRAN or an IP UTRAN with a transport layer control plane 
protocol no address (i.e. ATM address or IP address) or transport bearer 
reference (i.e. SUGR parameter or UDP port) has to be conveyed to a DHO node 
or leaf Node B to direct a transport bearer between the DHO node or leaf Node 
B and a hierarchicaUy higher DHO node or the RNC. In these cases the 
transport bearer is estabUshed from the hierarchically higher node (i.e. a DHO 
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node or the RNC) and the hierarchicaUy lower node does not have to know the 
destination parameters of the uplink direction of the transport bearer in 
advance. However, the hierarchically lower node has to be prepared in advance 
for the coming transport bearer establishment and it has to allocate 
destination parameters (ATM address and SUGR parameter or IP address and 
UDP port) for the downlink direction of the transport bearer to be used when 
the transport bearer is estabUshed. These parameters are returned to the RNC 
in response to the message that prepares the hierarchically lower node for the 
coming transport bearer establishment from a hierarchically higher node. 

To direct a transport bearer between a DHO node and a hierarchically lower 
DHO node or leaf Node B (in the DHO node tree) in any type of UTRAN (i.e. an 
ATM UTRAN or an IP UTRAN with or without a transport layer control plane 
protocol), the RNC conveys to the DHO node the destination parameters (Le. 
ATM address and SUGR parameter or IP address and UDP port) for the 
downlink direction of the transport bearers. This is information that is not 
included in regular NBA? (or RNSAP) messages. The RNC had previously 
retrieved these destination parameters from the hierarchicalfy lower DHO node 
or leaf Node B, when this hierarchicaUy lower node was prepared for or 
received direction for the estabKshment of the transport bearer towards the 
hierarchically higher node. 

Note that vihen a node estabUshes a transport bearer towards a hierarchically 
lower node, this transport bearer is from the viewpomt of the hierarchically 
lower node a transport bearer towards a hierarchicaUy higher node. 



Along with the transport bearer direction information the RNC may also send 
explicit QoS information to be used for the inter-Node B transport bearers. 
This may be e.g. in the form of DiffServ code points, QoS class indications or 
bandwidth (and possibly delay) indications. However, the required QoS 
information may also be impUcidy derived from the DCH characteristics 
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signaled via NBAP (and possibly RNSAP). Yet a possibiUty is to copy the QoS 
class used for the transport bearers towards the hierarchically higher node (in 
the DHO node tree) for the transport bearers towards the hierarchically lower 
node(8) (in the DHO node tree). 

In some cases a changed DHO node tree impKes that several data paths need 
to be changed in order to form a complete Node B-RNC path for a macro 
diversity leg. In such cases the RNC may choose to synchronize the switching 
from old to new data paths at a certain CFN in order to avoid data loss. The 
RNC then associates with the DHO instructions a time indication (in the form 
of a CFN) that indicates the CFN when the DHO instructions are to be 
effectuated in the receiving node. 

To convey all these instructions to the involved Node Bs the RNC uses existing 
unchanged NBAP messages (and RNSAP messages), existing modified NBAP 
messages (and RNSAP messages) and even new NBAP mess^es (and RNSAP 
mess^es). 

One aspect of the DHO related sigaaling is associated with the inter-RNS case. 
In the inter-RNS case the D-RNC more or less relays the information between 
the S-RNC and the Node Bs, using RNSAP towards the S-RNC and NBAP 
towards the Node Bs. It is however not a strict relay, since the D-RNC converts 
between two protocols. 

Since the DHO related information in an RNSAP message sent firom the S-RNC 
to a D-RNC may be intended for any of the Node Bs in the RNS of the D-RNC, 
there must be a way for the S-RNC to indicate the intended recipient of the 
DHO related information. The preferred way to do this is to include a transport 
layer address (i.e. an IP address or an ATM address) of the intended recipient 
node together with the DHO related information that is included in an RNSAP 
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message. This transport layer address should be the same address as the one 
that is used to represent the node in the topology information, because this 
address is the only address of the node that the S-RNC is guaranteed to know. 
However, if the intended recipient node is the D-RNC, the included transport 
layer address may be any address of the D-RNC that the S-RNC knows, e.g. 
the one that is used in the topology information or the one that is used as the 
destiixation address for the transport bearer used for the concerned RNSAP 
message. Likewise a transport layer address may be associated with DHO 
related information in RNSAP messages sent in response from a D-RNC to a S- 
RNC. 

If inter-RNS DCH transport bearers are always terminated in the D-RNC 
(which is possible according to the 3GPP standard), then no extension or 
modification of the RNSAP signaling is needed for the inter-RNS case of 
distributed DHO functionality. Instead the D-RNC can handle the distributed 
macro diversity mechanisms (i.e. selection of DHO nodes, providing DHO 
instructions, etc.) within its own RNS by itself independently of the S-RNC 
(provided that the S-RNC has not indicated that the D-RNC must not perform 
DHO functionality for a particular macro diversity le^ . 

Wf.ali^np r a DHO node tree with ">^*»»Hiff>^ prntncols 

In another embodiment of the present invention the RNC realizes the DHO 
node tree (i.e. directs the transport bearers in accordance with the DHO node 
tree) using unmodified NBAP and RNSAP protocols. The regular message 
formats are used and no new parameters are introduced. 



It should be understood that this method to estabUsh the macro diversity i 
accordance with the (logical) DHO node tree is independent of the method Hit 
is used to obtain or create the (logical) DHO node tree. 
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The embodiment without protocol modifications can only be used in an IP 
UTRAN without an IP control plane protocol. The reasons for this will be 
apparent from the further description of the solution. 

5 Using existing unmodified NBA? means that no DHO instructions that require 

new types of parameters in the NBAP messages may be used. This has 
consequences for the direction of data flows, the QoS instructions for the inter- 
Node B transport bearers as well as the initiation of DHO functionality in a 
Node B. Another consequence is that only radio active Node Bs are arranged to 
10 act as DHO nodes. Non-radio active nodes, including D-RNCs (but excluding 

the SRNC), are not possible as DHO nodes. 

As in the embodiment with modified NBAP, a DHO node in an IP UTRAN 
allocates the same IP address and UDP port for all transport bearers related to 

15 the same DCH, That is, all the received data flows pertaining to the same DCH 

arrive at the same IP address and UDP port (including the downlink flow from 
a hierarchically higher node in the DHO node tree as well as uplink flows from 
hierarchically lower nodes). The DHO node looks at the source IP address of 
the received IP packets in order to distinguish IP packets from the different 

20 flows of the same DCH (e.g. a downlink flow and one or several uplink flows). 

This principle is crucial for the solution with unmodified protocols. 

In the description below a hierarchically higher or lower node always refers to 
the hierarchy of the DHO node tree of a DCH. 

25 

As will be seen below the initiation and termination of DHO functionality in a 
DHO node is tightly coupled with the direction of data flows in this solution. 

Existing NBAP messages and parameters allow the RNC to instruct a Node B of 
30 the destination IP address and UDP port that should be used in the uplink 
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direction of a DCH transport bearer towards a hierarchicaUy hi^er node. 
When the DHO functionality is not distributed, these parameters are an IP 
address and a UDP port of the RNC itself. NBA? does however not include any 
means for instructing a Node B of v^aX parameters to use for a transport 
bearer towards a hierarchically lower node, this is because there is no need for 
such instructions in a UTRAN without distributed DHO functionality. 

To direct a transport bearer between a DHO node or a leaf Node B (in the DHO 
node tree) and a hierarchically higher DHO node or the RNC, the RNC conveys 
to the DHO node or leaf Node B the destination IP address and UDP port to be 
used in the uplink direction of the transport bearer in the same way as in the 
solution v?i1h modified protocols. That is, in essence, unless the hierarchically 
hi^er node is the RNC itself, the RNC replaces an IP address and a UDP port 
of the RNC (that would have been included in the message if distributed macro 
diversity had not been used) by an IP address and a UDP port of the 
hierarchically higher DHO node. The receiving node returns the destination IP 
address and UDP port to be used in the downUnk direction of the transport 
bearer. 

histructions pertaining to transport bearers towards a hieraichically lower 
node, i.e. direction of a spUt data flow, are trickier and have to be coupled with 
the mechanism for initiation of DHO fUnctionaUty in a DHO node. 

As stated above the RNC cannot expUcitly instruct a DHO node of what 
destination IP address and UDP port to use for a transport bearer towards a 
hierarchically lower node. Actually, the RNC cannot even explicitly inform a 
Node B that it has been selected as a DHO node and when the DHO 
functionality should be initiated or terminated. Instead a DHO enabled Node B 
has to rely on impHcit information in the data flows to trigger initiation and 
termination of the DHO functionaHty and to find out where to direct spHt data 
flows. 
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A DHO eaabled Node B checdcs the source address of aU the IP packets it 
receives at the IP address and UDP port aUocated to the transport bearer(s) of 
a certain DCH. If a packet with a source address other than that of the next 
hierarchically higher node (or one of its next hierarchicaUy lower nodes if the 
Node B is already acting as a DHO node) is received, this packet has to 
originate from a hierarchicaUy lower node. This indicates to the Node B that it 
has become a DHO node for a new macro diversity leg of the concerned DCH 
and the destination IP address and UDP port to use for the spUt downlink flow 
for the new macro diversity leg are the same as the source IP address and UDP 
port of the received packet. The Node B then initiates the required DHO 
functionality and starts to perform spUtting and combining accordingly. This 
principle cannot be used in an ATM UTRAN or an IP UTRAN with a transport 
layer control plane protocol, because in these types of UTRAN a Node B cannot 
send data to a hierarchicaUy higher node, until the hierarchicaUy higher node 
has established the transport bearer towards the Node B. 

The Node B does not receive any explicit QoS instructions for the new 
transport bearer towards the hierarchicaUy lower node, so if needed, the Node 
B has to derive the required QoS information from the DCH characteristics 
(which is already known in the Node B) or copy the QoS class (e.g. DifEServe 
code points) used for the transport bearer of the same DCH towards the next 
hierarchicaUy higher node. 

When a Node B acting as a DHO node detects that a hierarchicaUy lower node 
is no longer using a macro diversity leg for a certain DCH, it should terminate 
the DHO functionaUty for that macro diversity leg. To detect that a 
hierarchicaUy lower node has stopped using a macro diversity leg for a certain 
DCH a DHO node maintains a counter (in its basic form denoted 
simpleAbsentUpUnkFramesCounter) for each DCH macro diversity leg. The 
simpleAbsentUpUnkFramesCounter counts the consecutive absent upUnk 
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frames, i.e. it is increased by one for each consecutive TTI for which no uplink 
frame is received from the DCH macro diversity leg. When the DHO node has 
not received any uplink frames for a certain DCH from a certain hierarchteally 
lower node for a preconfigured number (e.g. denoted 
maxAUowedAbsentFrames) of consecutive TTIs (alternatively for a certain 
preconfigured time period), the DHO node assumes that it should no longer act 
as a DHO node for the concerned macro diversity leg. Consequently the DHO 
node terminates the DHO functionahty for the concerned DCH macro diversity 
leg. With this DHO termination tri^er condition the maximum time period 
that a DHO node may maintain DHO functionaHty for a DCH macro diversity 
leg that is no longer being used by the hierarchically lower node is equal to 
maxErroneousDHOpCTiod « mjaxAUowedAbsentFrames x TTI. 

With the above described DHO termination trigger mechanism there is a risk 
that a DHO node misinterprets a temporary interruption in the frame flow (e.g. 
due to DTX or poor radio conditions) and terminates the DHO functionality for 
a macro diversity leg that is stiU being used. (This risk is most significant when 
the DCH Frame Protocol operates in the "silent" mode. Then the Node B wiU 
not send any uplink DCH FP data frame during a certain TTI if the data 
received from the UE has a TFI indicating "number of TB equal to 0" (which 
means that there is no user data for this DCH during this TTI), e.g. due to 
DTX. Otherwise, when the DCH Frame Protocol operates in the "normal" mode, 
the Node B always sends an uplink DCH FP frame for each TTI when a vaHd 
transmission has been received from the UE, except during certain error 
conditions.) To reduce this risk the trigger mechanism may be refined in 
various ways. One way is to modify the trigger condition such that when 
counting the consecutive absent uplink frames for a DCH macro diversity leg, 
absent frames are disregarded (not counted) for TTIs for which no uplink frame 
was received from any of the other macro diversity legs either (i.e. the other 
macro diversity legs that the DHO node combines). The counter with this 
property is denoted selectiveAbsentUplinkFramesCounter and its threshold 
value is denoted maxAllowedSelectiveAbsentFVames (which typically is smaller 
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than maxAUowedAbsentPrames). With this refinement the risk for erroneous 
termination of the DHO functionaUty for a macro diversitsr leg is very smaU. 
However, an undesirable consequence of the refinement is that the time period 
that a DHO node may maintain DHO ftmctionaHty for a macro diversity leg 
that is no longer being used is theoretically unbounded. To avoid this 
undesirable property the refined tri^car mechanism should be complemented 
■with an additional condition constituting an upper limit for the number of 
consecutive absent uplink firames, irrespective of vfhether uplink flrames are 
received fi-om the otha: macro diversiQr legs or not. That is, the 
simpleAbsentUplinklTramesCounter is re-instituted, but with a greater 
threshold value, upperUmitMaxAllowedAbsentErames (where 
upperUmitMaxAllowedAbsentPrames > maxAllowedAbsentPrames > 
maxAllowedSelectiveAbsentFrames). With this DHO termination trigger 
condition the maximum time period that a DHO node may maintain DHO 
fiinctionaHly for a DCH macro diversity leg that is no longer being used by the 
hierarctiicaUy lower node is equal to maxErroneousDHOperiod = 
upperLimitMaxAUowedAbsentF^ames x TTI. This is the preferred trigger 
mechanism for termination of the DHO functionaHty for a DCH macro diversity 
leg. 

Another, alternative, way to refine the DHO termination trigger condition is to 
reset the counter of consecutive absent uplink firames for a DCH macro 
diversity leg every time no uplink frame is received firom any of the other macro 
diversity legs (i.e. the other macro diversity legs that the DHO node combines). 
The counter with this property is denoted 

strictlySelectiveAbsentUplinkFramesCounter and its threshold value is 
denoted maxAllowedStrictlySelectiveAbsentFrames (which typically is smaller 
than both maxAllowedAbsentFrames and maxAllowedSelectiveAbsentFyames). 
However, if DTX is frequently used (and possibly if the radio conditions are 
poor), this trigger condition may cause a DHO node to erroneously maintain 
the DHO functionality for a DCH macro diversity leg (for which it should not 
longer act as a DHO node) for an arbitrary (unbounded) period of time. 
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Therefore also this refined trigger mechanism should be complemented with a 
simpleAbsentUplinkFramesCounter and an upper limit for the number of 
consecutive absent uplink frames (upperlimitMaxAUowedAbsentFrames), 
irrespective of whether uplink frames are received from the other macro 
diversity legs or not. With this DHO termination tri^er condition the 
maximum time period that a DHO node may maintain DHO functionality for a 
DCH macro diversity leg that is no longer being used by the hierarchically 
lower node is equal to maxErroneousDHOperiod - 
upperLimitMaxAUowedAbsentFrames x TTL 

Since a Node B acting as a DHO node is always is a radio active DHO node in 
the solution without protocol modifications, it knows whether the DCH Frame 
Protocol operates in the normal or silent mode for a DCH. Hence, it can adapt 
the DHO tenxiination trigger conditions accordingly. Preferably, higjier 
upperLimitMaxAllowedAbsentFrames and maxAliowedAbsentPrames values 
should be used when the DCH Frame Protocol operates in the normal mode 
than when it operates in the silent mode. It would also be possible (but 
probably nod preferable) to use different trigger mechanisms (e.g. different 
counters) for the different DCH Frame Protocol modes. 

A possible (and preferable) variation of all the above DHO termination trigger 
mechanisms is to let the DHO node terminate the DHO functionality for a 
macro diversity leg only if all the DCHs of the concerned UE fulfil the DHO 
termination trigger condition for the concerned macro diversity leg. This 
coordination of the DHO termination for the DCHs of the same UE would make 
the DHO termination trigger mechanism more accurate. (A corresponding 
coordination of the DHO initiation mechanism is however not possible, 
because the destination IP address and UDP port to be used for the split 
downlink flows are supplied by uplink packets separately for each DCH macro 
diversity leg.) 
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Another possible (but probably not preferable) variation of the trigger 
mechanisms for termination of DHO functionattly is to use timers instead of 
frame counters, but tiiis variation would probably perform worse, since the TTI 
may be different for different DCHs. (Adapting the timeout value for the timers 
to the TTI of each DCH would eliminate this problem, but then there would in 
practice be no difference between running a timer and counting TTIs.) 

If a DHO node were still to naisinterpret a temporary interruption in the frame 
flow and erroneously terminate the DHO functionaKty for a certain DCH macro 
diversity leg, then the DHO functionaUty would be reinitiated (according to the 
above described DHO initiation mechanism) as soon as an uplink frame is 
received from the concerned DCH macro diversity leg. 

Using impUcit information in the data flow to trigger termination of DHO 
functionaHty (as described above) inevitabty means that a DHO node will 
maintain DHO functionaUty for a DCH macro diversity leg for a period of tune 
after the point in time when the hierarchically lower node stopped sending 
uplink frames on the concerned transport bearer. Consequentiy the DHO node 
(denoted A to simplify this description) will keep sending spUt downlink frames 
to an IP address and UDP port that arc no longer allocated to this DCH 
transport bearer in the hierarchically lower node (denoted B). 

If the hierarchically lower node (B) has reallocated this IP address and UDP 
port to another DCH transport bearer (towards another hierarchically higher 
node C (note that node B and node C may be the same node but for different 
DCHs)), this situation will cause the DHO functionality to malfunction in the 
hierarchically lower node (B). The packets that tiie hierarchically lower node 
(B) receives from the erroneously spUtting DHO node (A) has a different source 
IP address and UDP port than the packets received from the correct 
hierarchically higher node (C). Thus, if the hierarchically lower node (B) is DHO 
enabled, it will interpret the erroneously spUt packets from the old 
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hierarchically higher node (A) as packets from a new hierarchically lower node 
and thus will initiate DHO ftinctionaUly for what it believes to be a new macro 
diversity leg towards a hierarchically lower node (whereas it actually is an old 
macro diversity leg towards the old hierarchically higher node (A) which the old 
hierarchically higher node (A) has not stopped using yet). If the hierarchically 
lower node (B) is not DHO enabled, the situation may cause unpredictable 
behaviour in the hierardhically lower node (B). 

To avoid this problem a Node B must make sure not to reallocate an IP 
address-UDP port pair for a time period no shorter than 
maxErroneousDHOperiod. After this time period a Node B may safely 
reallocate an IP address-UDP port pair, since any DHO functionality using this 
IP address-UDP port pair in a hierarchically higher DHO node is surely 
terminated by then. This grace period for reallocation of IP address-UDP port 
pairs is a new functionaUty m a Node B. Hence, legacy (non-H-DHO aware) 
Node Bs in general cannot be used as leaf Node Bs in the solution with 
unmodified protocols. However, if a legacy (non-H-DHO aware) Node B filters 
incoming packets based on the source IP address (or source IP address and 
UDP port) such that packets with an unejqjected source IP address (or 
unexpected source UDP port) are discarded, then this legacy Node B can be 
used as a leaf Node B in the solution with unmodified protocols. 



Provided that a Node B uses an appropriate grace period for reallocation of IP 
address-UDP port pairs, a packet containing an erroneously split frame {from a 
hierarchically higher DHO node that has not stopped using an old transport 
bearer yet) will be received at an IP address-UDP port pair that is not in use. 
The Node B will then return a Destination Unreachable ICMP message (with 
the Code set to *port unreachable'. To improve the DHO termination 
mechanism a DHO node may use the reception of this ICMP message as an 
indication that the DHO functionaHty for the concerned DCH macro diversity 
leg should be terminated. The above described counter based DHO termination 
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txi^er mechanisms should preferably be complemented with this ICMP based 
trigger mechanism in order to speed up the DHO termination and thereby save 
transmission resources. 

5 All the methods for identifying the originating Node B of an uplink Node 

Synchronisation DCH FP control frame that were described for the 
embodiment with modified NBA? (and RNSAP) can be used also for the 
embodiment with unmodified protocols. 

10 Parts of the special aspects associated with the inter-RNS case are the same 

for this embodiment as for the embodiment using modified NBAP and RNSAP- 
In the inter-RNS case the D-RNC more or less relays the infomiation between 
the S-RNC and the Node Bs, using RNSAP towards the S-RNC and NBAP 
towards the Node Bs. It is however not a strict relay, since the D-RNC converts 

15 between two protocols. 

If inter-RNS DCH transport bearers are always terminated in the D-RNC 
(which is possible according to the 3GPP standard), then no extension or 
modification of the RNSAP signaling is needed for the inter-RNS case of 
distributed DHO functionality. Instead the D-RNC can handle the distributed 
macro diversity mechanisms (i.e. selection of DHO nodes, providing DHO 
instructions, etc.) within its own RNS by itself independently of the S-RNC 
(provided that the S-RNC has not indicated that the D-RNC must not perform 
DHO functionality for a particular macro diversity leg). 

An inter-RNS aspect that is special to the embodiment using unmodified 
protocols is that assuming that the principle of not terminating inter-RNS DCH 
transport bearers in the D-RNC is used, then a D-RNC cannot be selected as a 
DHO node, because the required DHO related instructions cannot be conveyed 
from the S-RNC. In addition, the D-RNC does not have an allocated IP address- 




70 



UDP port pair to which the S-RNC could direct the data flows from 
hierarchically lower Node Bs. 

To summarize, the method for selecting a DHO node, i.e. a Node B or an RNC 
comprising {and executing) a macro diversity functionality in a mobOe 
teleconmiunication system wherein the macro diversity functionality is 
distributed to a Radio Network ControUer, RNC, and its connected Node Bs in 
said network, comprises according to the present invention the steps of: 

1801. Obtain topology information comprising a hop-by-hop route from the 
RNC to each of its connected Node Bs and at least one metric for each hop 
in the route, 

1802.Use an algorithm for selecting a DHO node. 

The method above may be implemented by a computer program product. The 
computer program product is directly loadable into the internal memory of a 
computer within a Radio Network ControUer in a mobile telecommunication 
network, and comprises the software code portions for performing the steps of 
said method- Furthermore, the computer program product is stored on a 
computer usable medium, and comprises readable program for causing a 
computer, within a Radio Network ControUer in a mobile telecommunication 
system, to control an execution of the steps of said method. 

Thus, the RNC in accordance with the present invention comprises means for 
obtaining topology information comprising a hop-by-hop route from the RNC to 
each of its connected Node Bs and at least one metric for each hop in the 
route, and means for using an algorithm for selecting a DHO node. 



Eacecuting macro diversity 
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When the DHO nodes, also referred to as macro diversity nodes, are selected 
according to the method and arrangements of the present invention, the DHO 
nodes perform the following steps: 

For the downlink: 

5 The DHO nodes are adapted to split the downlink flow and to forward the 

resulting flows according to the instructions received from the RNC using the 
transport bearers previously established according to the instructions received 
from the RNC. The instructions to direct the data flows between the involved 
nodes may comprise IP addresses and UDP ports in an IP-based UTRAN or 
10 ATM addresses and SUGR references in an ATM-based UTRAN. 

When unmodified NBA? and RNSAP is used the DHO nodes may be adapted to 
split the downlink flow and to forward the resulting flows according to implicit 
information in the uplink data flow received from hierarchically lower nodes. 
This implicit information consists of source IP addresses and UDP ports 
15 retrieved from the IP header and UDP header of received upliak-packets^ 

For the uplink: 

The DHO nodes are adapted to combine the uplink flows to a single uplink flow 
that is forwarded according to the instructions received from the RNC using a 
previously established transport bearer. The instructions may comprise IP 
20 addresses in an IP-based UTRAN or ATM addresses or SUGR parameters in an 

ATM based UTRAN, When unmodified NBAP and RNSAP are used the DHO 
nodes are adapted to identify the uplink flows to be combined through 
information retrieved from uplink packets received from hierarchically lower 
nodes. 

25 The Node Bs with DHO functionality preferably use an adaptive timing scheme 

to optimise the trade-off between delay and frame loss in the uplink 
combining. The timing scheme is however not within the scope of the present 
invention. 
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In the drawings and specification, there have been disclosed typical preferred 
embodiments of the invention and, although specific terms are employed, thsy 
are used in a goieric and descriptive sense only and not for purposes of 
limitation, the scope of the invention beii^ set forth in the foUowii^ claims. 
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CLAIMS 

1. A method for selecting one or more Diversity Handover, DHO, nodes, such 
as a Node B or a Radio Network Controller, RNC, executing a macro 
diversity functionalily, in a mobile telecommunication network wherein the 
macro diversity functionalily is distributed to a RNC and its connected Node 
B(s) in said network, the method is characterised by the steps of: 

a. -obtaining topology information comprising a hop-by-hop route from the 
RNC to each of its connected Node Bs and at least one metric for each hop 
in the route, and 

b. -using an algorithm for selecting one or more DHO node(s), whereby the 
algorithm comprises the steps of: 

-forming a macro diversity tree of the routes by means of the obtained 
topology information, and 

-selecting the Node B(s) and/or the RNC, that results in the best 
acciunulated metric for all potential data flows between the RNC and 
its connected Node B(s) in the macro diversity tree of routes, as the 
DHO node(s). 

2. The method according to daim 1, wherein the topology information further 
comprises for each non-DHO enabled node in the topology information an 
indication of the closest DHO enabled node. 

3. The method according to any of claims 1-2, wherein the forming-step 
comprises the further steps of: 

-identifying branching nodes in said tree of routes, and 

-identifying the relative interconnections of said branching nodes and the 
connections to Node Bs and the RNC of said branching nodes. 

4. The method according to any of claims 1-3, wherein the at least one metric 
comprises a delay metric and a generic cost metric and that the step of 
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selecting the DHO Node(s) with the best accvunulated metric comprises the 
steps of: 

-selecting the DHO node(s) resulting in the smallest accumulated cost for 
aU potential data flows between the RNC and its connected Node B(s) in the 
macro diversity tree, as the DHO node(s), 

if the accumulated cost is substantially the same for two potential DHO 
nodes, 

selecting as the DHO node the potential DHO node that results in the 
smallest accumulated delay metric for all potential data flows between the 
RNC and its coimected Node B(s) in the macro diversity tree. 

5. The method according to any of claims 1-3, wherein the at least one metric 
comprises a generic cost. 

6. The method according to any of claims 1-3, wherein the at least one metric 
comprises a delay metric. 

7. The method according to any of claims 1-4 or 6, wherein the method 
comprises the farther steps of: 

c. -checking that a maximum allowed delay is not exceeded for a data path 
for the selected DHO node by using the delay metric from the topology 
information, and 

if the maximum allowed delay is exceeded, 

-performing a delay reduction procedure until the maximum allowed 
delay is not exceeded- 

8. The method according to claim 7, wherein the method comprises the 
further step of: 

-combining the delay metric with node synchronisation measurement in 
order to determine if the maximum delay is exceeded. 

9. The method according to any of claims 7-8, wherein the delay reduction 
procedure comprises the step of: 

-removing already selected macro diversity enabled nodes. 
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10. Hie method according to any of claims 1-9, wherein the topology 
information is obtained thorough manual or semi-automatic management 
operations in the RNC. 

11. The method according to any of claims 1-9, wherein the topology 
informiation is obtained via a link state routing protocol used in the 
transport network. 

12. The method according to any of claims 1-9, wherein the topology 
information is obtained by using a traceroute mechanism that allows the 
RNC to discover the hop-by-hop route to each Node B. 

IS.The method according to any of claims 1-9, wherein the topology 
information is obtained by retrieving the topology information from a RNC 
in the network. 

14. The method according to any of the previous claims, wherein the method 
comprises the further steps of: 

-preparing DHO related signalling messages to be conveyed to a Node B 
that is a part of a macro diversity tree, 

-including in at least one of the signaling messages one or more transport 
layer addresses and one or more transport bearer reference parameters in 
order to direct one or more inter-Node B data flows of the macro diversity 
tree, and 

-sending said at least one signaling message to said Node B. 

15. The method according to the previous claim, wherein the including-step 
comprises the further step of: 

-replacing the transport layer address and transport bearer reference 
parameter of an RNC by the transport layer address and transport bearer 
reference parameter of the selected DHO node in a regular signaling 
message sent to a Node B in order to direct a data flow between said Node B 
and a hierarchically higher DHO node. 

le.The method according to any of claims 14 or 15, wherein the induding-step 
comprises the further step of: 



76 

-including one or more transport layer address and one or more transport 
bearer reference parameter of one or more Node Bs in a signalling message 
sent to a DHO node in order to direct one or more data flovre between said 
DHO node and one or more hierardiically lower Node Bs. 

17. The method according to any of the claims 14-16, wherein said transport 
layer addresses are IP addresses and said transport bearer reference 
parameters are UDP ports. 

18. The method according to any of the claims 14-16, wherein said transport 
layer addresses are ATM addresses and said transport bearer refer^ce 
parameters are SUGR parameters. 

IQ.The method according to any of claims 14-18, further comprising the step 
of: 

-including in the signaling message Quality of Service (QoS) indications for 
the data flow(s) to be directed. 

20. The method according to any of claims 14-18, further comprising the step 
of: 

- including timing parameters in the signaling message to be used in the 
uplink combining procedure in the Node B receiving said sipialing 
message. 

21. The method according to any of claims 14-18, further ccwnprising the step 
of: 

-including a time indication indicating in the signaling message when the 
DHO related signalling message are to be effectuated in the Node B 
receiving said signaling message. 

22. The method according to claim 21, wherein said time indication is a 
connection frame number, CPN, pertaining to a Dedicated Channel Frame 
Protocol, DCH FP, in a UMTS Terrestrial Radio Access Network, UTRAN. 

23. The method according to any of claims 14-22, wherein said signaling 
message is sent from a RNC. 
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24. The method according to claim 23, whereia said signaling message is a 
NBAP message. 

25. A computer program product directly loadable into the internal memory of a 
computer within a Radio Network Controller in a mobile triecommunication 
network, comprising the software code portions for performing the steps of 
any of claims 1-24. 

26. A computer program product stored on a computer usable medium, 
comprising a readable program for causing a computer, within a Radio 
Network Controller in a mobile telecommunication network, to control an 
execution of the steps of any of the claims 1-24. 

27. A Radio Network ControUer, RNC, adapted for selecting a DHO node, e.g. a 
Node B or a RNC executing a macro diversity functionality in a mobile 
telecommunication system, wherein the macro diversity functionaKly is 
distributed to a Radio Network Controller, RNC, and its connected Node Bs 
in said network, the RNC is cliaxacterised in that it comprises: 

means for obtaining topology information comprising a hop-by-hop route 
from the RNC to each of its connected Node Bs and at least one metric for 
eadh hop in the route, and 

means for using an algorithm for selecting one or more DHO node(s), 
whereby said means comprises fiirther: 

means for forming a macro diversity tree of the routes by means of the 

obtained topology information, and 

means for selecting the Node B(s) and/or the RNC, that results in the 
best accumulated metric for all potential data flows between the RNC 
and its coimected Node B(s) in the macro diversity tree of routes, as 
the DHO node(s). 

28.A method for providing DHO related instructions to a Node B that is a part 
of a diversity handover connection in a mobile telecommunication network 
wherein the macro diversity fanctionaUty is distributed to a Radio Network 
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ControUer. RNC, and its connected base stations in said network, wherein 
the method is characterised by the steps of: 

- including in a signaling message one or more transport layer addresses and 
one or more transport bearer reference parameters in order to direct one or 
more data flows of the macro diversity connection, and 
sending said signaling message to said Node B. 

29. A Radio Network Controller, RNC, for providing DHO related instructions to 
a Node B that is a part of a diversity handover connection in a mobUe 
telecommunication network wherein the macro diversity functionahty is 
distributed to a Radio Network Controller, RNC, and its connected base 
stations in said network, wherein the RNC is characterised in that it 
comprises means for including in a signaling message one or more 
transport layer addresses and one or more transport bearer reference 
parameters in order to direct one or more data flows of the macro diversity 
connection, and means for sending said signaling message to said Node B. 
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Abstract 

The present invention relates to methods and arrangements for selecting one or 
more Diversity Handover (DHO) nodes, such as a Node B or a Radio Network 
5 ControUer (RNC) executing a macro diversity functionaHty, in a mobile 
telecommunication system wherein the macro diversity functionaKty is 
distributed to a RNC and its connected Node B(s) in said network. The method 
comprises the steps of: , 

a. -obtaining topology information comprising a hop-by-hop route from the 
10 RNC to each of its connected Node Bs and at least one metric for each hop 

in the route, and 

b. -using an algorithm for selecting one or more DHO node(s), whereby the 
algorithm comprises the steps of: 

-forming a macro diversity tree of the routes by means of the obtained 
15 topology information, and 

-selecting the Node B(s) and/or the RNC, resulting in the best accumulated 
metric for aU potential data flows between the RNC and its connected Node B(s) 
in the macro diversily tree of routes, as the DHO node(s). 
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